Re: [PATCH] demonstrate git-commit --dry-run exit code behaviour
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 24, 2014, 17:16 UTC
- Message-ID
- <xmqqha7obfe6.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20140222083423.GF1576@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 23 quoted lines
> On Fri, Feb 21, 2014 at 12:21:13PM -0800, Junio C Hamano wrote: > >> Tay Ray Chuan <rctay89@gmail.com> writes: >> >> > In particular, show that --short and --porcelain, while implying >> > --dry-run, do not return the same exit code as --dry-run. This is due to >> > the wt_status.commitable flag being set only when a long status is >> > requested. >> >> I am not sure if --short/--porcelain should even be accepted by "git >> commit" in the first place. It used to be that "git status" and >> "git commit" were the same program in a different guise and "git >> status <anything>" were merely a "git commit --dry-run <anything>", >> but the recent push is in the direction of making them totally >> separate in the end-user's minds. So if we want a proper fix, I >> would actually think that these options should *error out* at the >> command line parser level, way before checking if there is anything >> to commit. > > I do not think they are any less useful than "git commit --dry-run" in > the first place. If you want to ask "what would happen if I ran commit > with these arguments", you can get the answer in any of several formats > (and --porcelain is the only machine-readable one).
Hmph.
> I have never found "commit --dry-run" to be useful, but I assumed that > somebody does.
Same here, and I did not really consider "commit --short" was intentionally a valid short-hand for "commit --dry-run --short", but its working as such was an accident, hence my comment.