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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
