Thread (1 message) 1 message, 1 author, 2019-06-03

Re: [Proposal] git am --check

From: Junio C Hamano <hidden>
Date: 2019-06-03 18:16:27

Duy Nguyen [off-list ref] writes:
On Mon, Jun 3, 2019 at 4:29 PM Christian Couder
[off-list ref] wrote:
quoted
On Sun, Jun 2, 2019 at 7:38 PM Drew DeVault [off-list ref] wrote:
quoted
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".
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help