Re: [Proposal] git am --check
Duy Nguyen <pclouds@gmail.com> writes:
Show 20 quoted lines
> On Mon, Jun 3, 2019 at 4:29 PM Christian Couder
> <christian.couder@gmail.com> wrote:
>>
>> On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault <sir@cmpwn.com> wrote:
>> >
>> > This flag would behave similarly to git apply --check, or in other words
>> > would exit with a nonzero status if the patch is not applicable without
>> > actually applying the patch otherwise.
>>
>> `git am` uses the same code as `git apply` to apply patches, so there
>> should be no difference between `git am --check` and `git apply
>> --check`.
>
> One difference (that still annoys me) is "git apply" must be run at
> topdir. "git am" can be run anywhere and it will automatically find
> topdir.
>
> "git am" can also consume multiple patches, so it's some extra work if
> we just use "git apply" directly, although I don't think that's a very
> good argument for "am --check".
Another is that "am" has preprocessing phase performed by mailsplit that deals with MIME garbage, which "apply" will totally choke on without even attempting to cope with.
I haven't carefully read the "proposal" or any rfc patches yet, but would/should the command make a commit if the patch cleanly applies?
I wonder if a "--dry-run" option is more useful (i.e. checks and reports with the exit status *if* the command without "--dry-run" would cleanly succeed, but never makes a commit or touches the index or the working tree), given the motivating use case is a Git aware MUA that helps the user by saying "if you are busy you could perhaps skip this message as the patch would not apply to your tree anyway".