Re: Announce: Linux-next (Or Andrew's dream :-))

Linus Torvalds
2008-02-13T00:45:29Z

On Tue, 12 Feb 2008, David Miller wrote:
>
> At 1500 changesets, a merge conflict shows up about once
> every day or two as 2.6.N nears it's release into final
> as bug fixes trickle in.
>
> I find using GIT to fixup merge errors on a tree of that
> scale to be really painful. And it only fixes up the final
> result in a merge changeset.

Heh. I've had the reverse situation: "git rebase" often results in *more*
conflicts than "git merge" (ie "pull").

But one issue is also that when conflicts happen, different people are
used to different things. I'm particularly used to merge-type conflicts,
and in fact there's some fairly advanced support in git for helping
resolve them that people who *don't* do merge-level conflict resolution
may not even be aware of.

In particular, if you want to try it, do something that conflicts and then
do

gitk --merge

to see what the conflict is all about. That is just fancy shorthand for

gitk HEAD...MERGE_HEAD --

so what it does is to show only the relevant history (the three dots means
that it's a _symmetric_ set difference from HEAD to MERGE_HEAD) for the
merge, and only for the particular files that had conflicts!

This often means that even when you merge a thousand commits (or the thing
you merge *into* has thousands of commits since the merge base, which is
the common case for me), you actually only see a couple of commits - only
the ones that actually modified the conflicting files!

(If you have many files that conflict, you can further narrow it down to
just one at a time by explicitly listing the file/directory you want to
work on, ie do "gitk --merge <pathname-here>").

> Let me give you a good example, just yesterday I had to rebase
> my net-2.6 tree a few times. It's because I put a patch in there
> that the person said was OK but it broke the build. There is
> zero reason for me to push that tree to Linus with the bad
> commit and the revert, it's just noise and makes the tree harder
> for people to review.

Actually, better than rebase in that situation is to just remove the bad
commit. Yes, you'd use "rebase" for it, but you'd use it not to move the
whole series to a newer place, you'd use it just to rebase the commits
*after* the commit you remove.

This is something where I actually think git could and should do better:
git has the capability to act as more of a "quilt replacement", but
because it wasn't part of the original design, we never actualy exposed
the simple queue management commands to do this (stgit does things like
that, though).

So if you haven't pushed out, right now you'd have to do this stupid
thing:

[ start (and activate) a 'fixup' branch at X ]
git checkout -b fixup X

[ edit edit edit to fix it up ]
..

[ commit the fixed state ]
git commit --amend

[ go back to the old broken state ]
git checkout master

[ now, rebase 'master' on top of the fix ]
git rebase fixup

[ ok, done, forget the fixup branch ]
git branch -d fixup

and I don't discourage this kind of behaviour at all, but it is only good
iff:

- you have not pushed things out (obviously), so nobody ever even notices
that you've fixed up stuff

- you haven't pulled anything from outside (so you aren't trying to
rebase other peoples commits).

If you *really* want to try to do this even across merges you've done,
there is fancy a "--preserve-merges" thing that you can try to use
(needs "-i" to work, but "-i" is often cool for other reasons too!)

Basically, what I'm trying to say is that "git rebase" can be used in
fancy ways to do things that people outside your repository will never
even *know* were done. It's only when outsiders can see the effects of git
rebase that you're in trouble!

Linus