Nicolas Sebrecht <nicolas.s....@gmx.fr> writes: > The 12/07/12, Junio C Hamano wrote: > >> It does not matter at all that 0001-foo.patch only has a single >> patch. If you are going to fix up the patch after you saw "git am" >> failed, you will be fixing .git/rebase-apply/patch with your editor >> and re-run "git am" without arguments, at which point "git am" will >> not look at your 0001-foo.patch file at all. > > Hugh! Didn't know that. > > Is it actually expected from users to manually edit > .git/rebase-apply/patch path? I can't find any reference about that in > the documentation and it really sounds like interfering with the git > internals. > > Shouldn't git-am/git-rebase expose this to the user (I'm thinking about > something like > > git am --edit-offending-patch > git am --fix-patch
I doubt it would be very useful. As Paul says, it is a powerful way to work, but it is not for everybody, and more importantly, it is not the only way to work with the patch, once the user knows where it is. The first problem before any of that is that we didn't tell the user where the patch is. You can re-run "git am" with different options like reject, "-3", and/or with a reduced context and many cases are handled without having to know where the patch is at all, but if the user starts wanting to know where the patch is because she wants to do things beyond that, we should just tell her where it is, instead of adding a yet another option to run an editor on it, still without telling her where it is. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
