All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Andy Parkins <andyparkins@gmail.com>
Cc: git@vger.kernel.org, "Francis Moreau" <francis.moro@gmail.com>
Subject: Re: git-am failed, what's next ?
Date: Thu, 22 Feb 2007 12:02:23 -0800	[thread overview]
Message-ID: <7v3b4yezao.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <200702221113.44338.andyparkins@gmail.com> (Andy Parkins's message of "Thu, 22 Feb 2007 11:13:42 +0000")

Andy Parkins <andyparkins@gmail.com> writes:

> On Thursday 2007 February 22 09:47, Junio C Hamano wrote:
>
>> If you have the pre-image blobs the patch was created against,
>> and the patch was created with git and records "index" lines
>> like these correctly:
>>
>>         diff --git a/builtin-config.c b/builtin-config.c
>>         index 0f9051d..f1433a4 100644
>>
>> then you can tell git to fall back on 3-way merge to apply the
>> patch.  After seeing "git am ./mbox" fail, you could try
>
> Magic.  I had no idea about this.  Could it be made even more
> magical by doing this for you?

You can start with --3way from the beginning, not just after
seeing it fail.

In the earlier description, I made it sound as if "-3" is an
option for recovery, but that is not the case.

Running "git am" without mbox parameter and an existing .dotest/
is the instruction for "git am" to continue, and the first thing
it does when told to continue is different depending on if
either --skip or --resolved is given.  --skip makes it skip the
patch.  --resolved takes the index, uses the metainfo to make a
commit.  Lack of these options makes it re-try the one recorded
in .dotest/next file.  After that, if it fails (and --skip would
not fail), it stops.  Otherwise it goes on to the next patch.

The example you referred to as "magic" is just a normal "retry it"
codepath but running with the "--3way" option.

The 3-way fallback is not enabled by default.  A minor reason
for this is that it did not exist in the original and is an
optional feature that was added later on.

But the real reason is that as a principle, git tools err on the
safe side by default, just like our use of "git-apply" in
"git-am" does not allow fuzz in the patch nor reducing context
by default for strictness.  That way, the patch application
process is stopped and gives the non-interactive user a chance
to inspect _why_ the patch does not apply, before deciding to
continue, either with fuzz'ed patch application, fixing the
patch text, or falling back on 3-way.

But these days, I almost always run:

	$ git am -3 -s ./mbox

and inspect the ones that actually used 3-way fallback after the
fact.  It _might_ make sense to add a configuration option to
default to -3 (or -s for that matter), like:

	[am]
		signoff
                threeway

and do something like this:

---
 git-am.sh |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/git-am.sh b/git-am.sh
index 6db9cb5..c0395f5 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -109,6 +109,7 @@ prec=4
 dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary= resolvemsg=
 git_apply_opt=
 
+has_opt=
 while case "$#" in 0) break;; esac
 do
 	case "$1" in
@@ -155,8 +156,21 @@ do
 	*)
 	break ;;
 	esac
+	has_opt=t
 done
 
+if test -z "$has_opt"
+then
+	if test true = "$(git config --bool am.signoff)"
+	then
+		sign=t
+	fi
+	if test true = "$(git config --bool am.threeway)"
+	then
+		threeway=t
+	fi
+fi
+
 # If the dotest directory exists, but we have finished applying all the
 # patches in them, clear it out.
 if test -d "$dotest" &&

  reply	other threads:[~2007-02-22 20:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-22  8:22 git-am failed, what's next ? Francis Moreau
2007-02-22  8:48 ` Andy Parkins
2007-02-22 10:09   ` Francis Moreau
2007-02-22  9:47 ` Junio C Hamano
2007-02-22 10:38   ` Francis Moreau
2007-02-22 19:30     ` Junio C Hamano
2007-02-22 10:50   ` Francis Moreau
2007-02-22 11:13   ` Andy Parkins
2007-02-22 20:02     ` Junio C Hamano [this message]
2007-02-22 19:11 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v3b4yezao.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=andyparkins@gmail.com \
    --cc=francis.moro@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.