Git policy: git merge or git cherry-pick

[Dmitry Kazakov]

On Mon, Jan 31, 2011 at 4:27 PM, Lukast dev <> wrote:

>
> boud:
>
...

> o but then the development branch should never be deleted, otherwise
> we have one big commit that nobody can every bisect anymore and never
> figure out the history of
>

I'm not sure the latest statement is true. If the branch is merged into
master and then deleted, the history of the branch will still be there. You
will see a "ring" in `gitk --all` interface.

o development branches may not compile sometimes, do we want to see these
commits in master?
o cherry-picking is effectively an equivalent to rebasing, especially when
there are conflicts present.
o cherry-picking and rebasing is not always clean. Example: imagine you did
a merge from master to branch in the middle of the development of the
branch. Rebasing (cherry-picking) of such a branch is not safe.

As for me, i'm almost agree with sebsauer. If you have a small local branch
that will never be published, just rebase it. If you have once published
your branch, you should do no rebasing, cherry-picking or other rewriting of
history.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20110131/b14fad15/attachment.htm>