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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html