Re: Cherry picking instead of merges.

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 4 Jul 2008, Johannes Sixt wrote:
> 
> FWIW, the same thing in different words is written in section
> 
> "Why bisecting merge commits can be harder than bisecting linear history"
> 
> of Documentation/user-manual.txt.

I don't think that's the same thign at all.

That section basically says "just keep things linear". Which I very much 
disagree with. Trying to keep things linear just doesn't work if you work 
together with other people - since you have to rewrite history.

So my argument was the exact _reverse_. Don't try to keep things linear, 
because it doesn't _work_ right. Do the merges. They will very seldom 
cause subtle merge problems (non-subtle ones are much more common, but 
trivial to handle), and they will mean that you can work effectively 
togethr with other people.

And then, _if_ you have a merge that you really cannot figure out why it 
breaks, at that point you can _temporarily_ linearize the git history 
after-the-fact just as easily as you would ever have done before-the-fact.

In other words: linearization throws away real and useful information. You 
can always linearize afterwards for bisection purposes or whatever, but 
you can never _un_linearize because you've thrown away the information.

So it's much better to just do merges and keep the history, and then there 
are ways to rewrite the history later if you really need it.

That said - I think it's good practice and perfectly sane to do things 
like git-rebase to rewrite the history in a _private_ tree that contains 
only your own modifications and has never been public (where "applied 
emailed patches from others" still counts as your own work).

The "don't linearize" mantra really only is about commits that have ever 
been in anybody elses repository (and whether they _came_ from there, or 
whether they came from you but were public to others is immaterial).

			Linus