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

Jakub Narebski [off-list ref] writes:

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.

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).

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

Jakub Narebski wrote:

Junio C Hamano wrote:

[...] 

quoted

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.

Original (not edited) version of patch generates nice merge conflict.

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.

Or at least some information what git-am is attempting before second 
'patch failed' error message...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Hi,

On Sat, 12 Aug 2006, Jakub Narebski wrote:

Why do we not record commit id in patch?

Because we do not have to.

There is a commit SHA1 which guarantees the integrity of the commit, and 
then you can generate the patch-id with

	$ git show $commit | git patch-id

And how git-rebase deals with this? 

AFAICT by cherry-picking the commit, and if nothing changed in the index, 
just ignoring the patch.

Hth,
Dscho

Jakub Narebski [off-list ref] writes:

Jakub Narebski wrote:

quoted

Junio C Hamano wrote:

[...] 

quoted

quoted

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.

Original (not edited) version of patch generates nice merge conflict.

The moral of the story is that either (1) you hand edit the
patch to apply cleanly to the target, or (2) if you do edit, do
not make it inapplicable to the preimage blob recorded in the
patch, so that -3 still would work.

quoted

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.

Or at least some information what git-am is attempting before second 
'patch failed' error message...

How about this?

diff --git a/git-am.sh b/git-am.sh
index 04f0119..aff4bb7 100755
--- a/git-am.sh
+++ b/git-am.sh

@@ -45,6 +45,12 @@ go_next () {
 	this=$next
 }
 
+cannot_fallback () {
+	echo >&2 "$1"
+	echo >&2 "Cannot fall back to three-way merge."
+	exit 1
+}
+
 fall_back_3way () {
     O_OBJECT=`cd "$GIT_OBJECT_DIRECTORY" && pwd`
 

@@ -52,19 +58,23 @@ fall_back_3way () {
     mkdir "$dotest/patch-merge-tmp-dir"
 
     # First see if the patch records the index info that we can use.
-    if git-apply -z --index-info "$dotest/patch" \
-	>"$dotest/patch-merge-index-info" 2>/dev/null &&
-	GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
-	git-update-index -z --index-info <"$dotest/patch-merge-index-info" &&
-	GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
-	git-write-tree >"$dotest/patch-merge-base+" &&
-	# index has the base tree now.
-	GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
+    git-apply -z --index-info "$dotest/patch" \
+    	>"$dotest/patch-merge-index-info" &&
+    GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
+    git-update-index -z --index-info <"$dotest/patch-merge-index-info" &&
+    GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
+    git-write-tree >"$dotest/patch-merge-base+" ||
+    cannot_fallback "Patch does not record usable index information."
+
+    echo Using index info to reconstruct a base tree...
+    if GIT_INDEX_FILE="$dotest/patch-merge-tmp-index" \
 	git-apply $binary --cached <"$dotest/patch"
     then
-	echo Using index info to reconstruct a base tree...
 	mv "$dotest/patch-merge-base+" "$dotest/patch-merge-base"
 	mv "$dotest/patch-merge-tmp-index" "$dotest/patch-merge-index"
+    else
+        cannot_fallback "Did you hand edit your patch?
+It does not apply to blobs recorded in its index."
     fi
 
     test -f "$dotest/patch-merge-index" &&