Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Mon, Jun 3, 2019 at 4:29 PM Christian Couder > <christian.couder@xxxxxxxxx> wrote: >> >> On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault <sir@xxxxxxxxx> 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".
