Re: How to resolve git-am conflict (possible bug)

Junio C Hamano wrote:

Jakub Narebski [off-list ref] writes:

quoted

Third, I wonder why it printed the same error message _twice_.

Do you have blob 7ea52b1?  Otherwise you would not see two "does
not apply" messages, so I suspect you do.  Does the patch
cleanly apply to that blob?

More likely explanation is that you edited the patch by hand for
some reason, and made it inapplicable to the base blob the
"index" line records.

Yes, I have edited "post-sub-rename" patch by hand (by script) in attempt
for it to apply cleanly to the top of "pre-sub-rename" development branch.
BTW patch applies cleanly to merge-base of the branch the patch is from and
the branch it is applied to.

Why do we not record commit id in patch? And how git-rebase deals with this? 

The first "patch does not apply" comes from ll. 363 of git-am.
After it fails because the patch does not apply to the version
of gitweb.perl in your index, since you told it to fall back to
three-way merge, l. 391 calls fall_back_3way, which inspects the
patch, finds the "index" line and notices that the patch claims
to apply to blob 7ea52b1, finds the blob in your repository, and
prepares a temporary index with "update-index -z --index-info"
on l. 58 successfully, tries to apply the patch again on l. 63.

However, the patch contents and the blob object name recorded on
the index line are not necessarily consistent if you hand edited
the patch (IOW, the context lines in the patch contents may not
match blob 7ea52b1).

It would be nice then if git-am was more verbose, for example
"Applying patch to blob 7ea52b1... gitweb/gitweb.perl" or something
like that.

And first complaint still apply: in git-am(1) there is precious few
documentation (or at least references) about _how_ to resolve merge
conflict or failed patch (does git-apply creates *.orig and *.rej 
files?)

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git