On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote:
The obvious advantage to rebasing in this case is that the blame
(misplaced though it may be), at least lands on a commit that made a
single small change, likely making the problem easier to diagnose.
(As opposed to the case of a large merge, where all you may know is that
somewhere in the hundreds of commits done on one side of the merge there
was a conflict with the hundreds of commits on the other side.)
I think a lot of people would see rebasing as an acceptable tradeof that
gives up a small amount of accuracy in assigning blame to individuals in
return for a large increase in ability to debug problems.
I suppose one response to that would be that it's important that people
learn how to work in parallel, that failures to do so are particularly
important failures in the process, and that it's therefore worth it to
make sure that such failures are always identified specifically as merge
failures.
It would be nice if merges, like patches, were broken up into somewhat
smaller units. There's an understandable desire to wait to the last
minute to actually commit to one's commits, but a willingness to do so a
little earlier might avoid some of the problems that seem to come from
having a lot of large merges happen all at once.
--b.
--
