From: Francis Moreau <francis.moro@gmail.com>
Date: Thu, 22 Feb 2007 10:38:51 GMT
Subject: Re: git-am failed, what's next ?
Message-ID: <38b2ab8a0702220238l14628f54s3165f050f6af5447@mail.gmail.com>
In-Reply-To: <7v8xeqh6bj.fsf@assigned-by-dhcp.cox.net>

Hi,

Junio C Hamano wrote:
> "git-am" deserves a section in the user-manual on its own.
> Perhaps the following can be massaged into JBF's User Manual,
> but probably with copyediting and spellfixes.
>

yes it's definitly something useful for me. Thanks for writing it !

> First, the basics.
> ------------------
>
> When "git am ./mbox" stops in the middle, you will find
> these files in the .dotest/ directory:
>

[snip]

> There are two strategies to resume an "am" that stopped because
> a patch does not apply.
>
> One is to fix the patch into applicable shape in whatever way
> you can think of, and attempt to apply it again, with "git am".
>
> The other is to update your index to the desired state after
> applying the given patch in whatever way you can think of, and
> continue with "git am --resolved".
>
> You can also choose not to continue, but skip one patch.  You
> can say:
>
> 	$ git reset --hard
>         $ git am --skip
>
> to skip that particular patch.  This advances 'next' and
> continues with the remainder.
>
> [jc: I think that is not what you want in your RFH, but I am
> spelling it out for inclusion in the User Manual -- this comment
> itself should be removed if somebody wants to include this
> message to the manual.]
>

nope, and this is quite well explained in the man page.

> Now, let's go on to "whatever way you can think of".
>
>
> Fixing patch text
> -----------------
>
> Linus's way is to visit the ./mbox file in the editor, remove
> the messages that have already been applied cleanly, edit the
> offending patch text to make it applicable.  Then:
>
> 	$ git reset --hard
>         $ rm -fr .dotest
>         $ git am edited-mailbox-file
>
> A variant of this approach is to edit .dotest/patch to make it
> applicable, and then say (without removing .dotest/ directory,
> of course):
>
> 	$ git am
>
> But these are probably reserved for people who are comfortable
> editing the patch text.
>

definitely not my case...

>
> Applying by hand
> ----------------
>
> If you (as most people) are not comfortable editing the patch
> text you can update your working tree to pretend that the patch
> applied cleanly.  You can do number of things:
>
>  * Use "git apply --index -C<n> .dotest/patch" to attempt
>    applying the patch with reduced context.
>
>  * Use "git apply --reject .dotest/patch" to get apply only
>    hunks that apply cleanly, while getting *.rej files.
>
>  * Use "GNU patch" with less strict options, perhaps like
>
> 	$ patch -p1 --fuzz=<n> --ignore-whitespace
>

why using 'patch' ? couldn't this be done by using 'git-apply' ?

Maybe these several choices could be proposed to the user when using
the interactive mode ?

>
>
> Letting git work harder
> -----------------------
>

[snip]

> This "3-way" is in fact a variant of "Applying by hand"
> strategy, and your goal is still to update the index into the
> shape the original patch should have made into.  After you
> resolve the conflict, you do "git add" the resolved path (or if
> the patch is about removing a path and if you do want to remove
> that path, then "git rm").  Make sure that "git diff --cached
> HEAD" output matches what you think .dotest/patch should have
> contained.  Then:
>
> 	$ git am --resolved
>
> to continue.
>

This part is really interesting.
-- 
Francis