Re: [PATCH] GIT commit statistics.

From: Junio C Hamano <junkio@cox.net>
Date: Nov 14, 2005, 03:33 UTC
Message-ID: <7vlkzr6gzz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46a038f90511131242p4692c74fn20c015998620b9f4@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> writes:

Show 10 quoted lines

> On 11/13/05, Junio C Hamano <junkio@cox.net> wrote:
>> ....  I
>> could do "git pull . origin" at this point, but that would
>> result in a useless mini-merge.  My tree is not public so I can
>> freely rebase to clean things up.
>>
>>         $ git rebase origin
>>         $ git show-branch
>
> What happens if there are conflicts during git-rebase?

Well, obviously you could resolve them ;-). But if you are rebasing just to reduce trivial mini-merges, it might make more sense to honestly record the merge if the rebase involves conflict resolution. After all, the reason rebase got conflicts is because the development trail by somebody else that has been already committed to the shared "master" branch overlapped what you were doing in your "master" branch, isn't it?

In your message you indicated that you use "format-patch" piped to "am". I think that is a better approach than "rebase" these days; the conflict can be handled easier with that approach, and if you use "--3way" flag you do not even have to worry about patches in your branch that is already there in the shared "master" (your "origin") branch.

So instead of running "git rebase origin" at this point, I may do something like this [*1*]:

	$ git-reset --hard origin
        $ git-format-patch -k --stdout origin ORIG_HEAD | git am -3 -k

The first step rewinds my "master" (the original is stored in ORIG_HEAD), and the second step extracts the commits that were in my master but not in origin in a patch form, an replay them on top of the "master" (which was rewound to "origin").

"git-am" would stop at the first unapplicable patch if there is a conflict, leaving the conflicting patch in .dotest/patch. I have to fix it up before going further. Here is how.

1. "git am" 3-way fallback would have kicked in, because I have
   all the blobs the patch is supposed to apply to, and my
   working tree and index is in a state just like when I am
   resolving a conflicting merge after a pull.  Clean up the
   conflict in the working tree, build-test and all as usual.

2. Run "git diff HEAD >.dotest/patch" to record what the patch
   should have been if it were to apply cleanly on top of the
   previous state.  If I did a noteworthy adjustment to the
   patch, I might also edit .dotest/final-commit to update the
   commit log message.

3. Then reset the working tree and index before the failed
   application of this patch with "git reset --hard".

After that:

	$ git am -3

would let me restart from that commit that did not replay well.

> Is there a cheap way to ask from a shell script whether the merge is
> truly trivial? I thought git-diff-tree would help me here, but it
> doesn't...

This was recently added by Linus to help git-merge do that:

	git-read-tree --trivial -m -u $O $A $B

The command exits with a non-zero status, without touching index nor working tree, when the merge is not "truly trivial". Otherwise it does its thing -- the trivial in-index merge is done, files in working tree updated and the only thing left for you to do is to create a commit having parent $A and $B.

Would that help?

[Footnote]

*1* This is what the "make rebase restartable" comment in TODO list is about, and I wanted to rewrite "rebase" to do exactly these two commands, but I got distracted ;-).