Git policy: git merge or git cherry-pick

[Cyrille Berger Skott]

On Monday 31 January 2011, Dmitry Kazakov wrote:
> 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.
Boudewijn was speaking of cherry-pick. 

> 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.

Yes further more, merge has a semantic associated with it. It is a single 
commit that brings a new feature (or refectoring...). While cherry-picking 
might give the nicest looking history, you would get one long linear history 
(unless you squash things... I guess). While with merge, if you look at the 
log, you get a branch between either more details about that specific commit, 
or go back further to the previous change in master.

Since basically, this is how the history would look:

HEAD
 ^
 |
...
 ^
 |
merge cool feature <- last commit for the feature <- an other one <- ...
 ^
 |
previous master commit


For me with merge, you have one commit in master, that can extend to several 
other commits if you look at the history, or you can ignore them.

The only problem is UI related, but sometimes you don't know which of the 
ancestor commit was "master"... qgit works nicely, but none of the webui 
interface seems to show it correctly.

-- 
Cyrille Berger Skott