Re: git-am failed, what's next ?
- From
Junio C Hamano <junkio@cox.net>
- Date
- Feb 22, 2007, 19:30 UTC
- Message-ID
- <7virduf0s1.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <38b2ab8a0702220238l14628f54s3165f050f6af5447@mail.gmail.com>
"Francis Moreau" <francis.moro@gmail.com> writes:
Show 18 quoted lines
>> 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' ?
The default operationg mode of 'patch' is less strict than git-apply is, and it can be told to be much less strict, so some people seem to like it. You do not have to use it unless your patch text is based on too far away version. I usually don't.
Also the above is not an exhaustive list. If you are handy with other tools to make patches that do not cleanly apply apply (e.g. wiggle), they can be used instead.
> Maybe these several choices could be proposed to the user when using > the interactive mode ?
I do not think so. As far as I remember, interactive mode helps the "Fixing patch text" strategy but not "Applying by hand" strategy. When a patch does not apply, you fix the text and re-apply, and [v]iew command is to review how you fixed the patch, for example.