Re: [PATCH] Re: git-am: indicate where a failed patch is to be found.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicolas Sebrecht <nicolas.s.dev@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]