Should "git apply --check" imply verbose?

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

 



TL;DR -- "git apply --reject" implies verbose, but the similar
"git apply --check" does not, which seems inconsistent.

Background:  A common (non-git) workflow can be to use "patch --dry-run"
to inspect whether a patch is feasible, and then use patch again
a 2nd time (w/o --dry-run) to actually apply it (and then work
through the rejects).

You can also do the above in a git repo, but you lose out because
"patch" doesn't (yet) capture the patched function names[1] in the
rejected hunks, making it hard to double check your work.

My initial thought was to replace the above two steps with
"git apply --check ..." and then "git apply --reject ..." so
that I could just abandon using patch altogether.

That works great, with just one snag that had me go reading the
source.  It seems that "git apply --reject" is verbose, and kind
of looks like the identical output I'd get if I used patch.  But
"git apply --check" is quite reserved in its output and doesn't
look at all like "patch --dry-run".  I initially believed that
"--check" was stopping at the 1st failure, based on the output.

Only when I read the source did I realize it was checking all the
hunks silently, and adding a "-v" would make it similar to the
output from "patch --dry-run".

Not a critical issue by any means, but having the "-v" implied
by "--check" (or perhaps having both default to non-verbose?)
might save other users from getting confused in the same way.

Thanks,
Paul.
--

[1] https://savannah.gnu.org/bugs/index.php?39819
--
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]