Ramkumar Ramachandra <artag...@gmail.com> writes:

> 50e4f75 (status: introduce status.short to enable --short by default,
> 2013-06-11) introduced a regression in git commit; it is now impossible
> to commit with status.short set.
> This happens because commit internally runs run_status() to set
> s->commitable and determine whether or not there is something to
> commit.  The problem arises from the fact that only STATUS_FORMAT_NONE
> (or STATUS_FORMAT_LONG) is equipped to set s->commitable.
> 7c9f7038 (commit: support alternate status formats, 2009-09-05) clearly
> states that --short and --porcelain imply --dry-run and are therefore
> only intended for display purposes.
> The bigger problem is that it is impossible to differentiate between a
> status_format set by the command-line option parser versus that set by
> the config parser.  So these two are exactly equivalent:
>   $ git -c status.short=true commit
>   $ git commit --short

Thanks for a report.  I think the analysis above is correct, and if
we want to ignore status.short but still want to honor --short from
the command line, your patch is a way to go.

As I said in the other message, I'll revert the merge of the topic
branch from 'master' for now, and queue this on top of the topic so
that we will have the preventive fix when the topic is in a better
shape for the other possible breakage on the "--branch" thing.

Having said that, even before the merge of that status.short
(e.g. v1.8.3), "git commit --short" did not work and that was
deliberate only because "git commit --dry-run" has long been an
equivalent for "git status", "--short/-z/--porcelain" were options
for "status", and therefore these options were made to imply

I have to wonder if that is a sane thing in the first place, now
that it has been quite a while since "git status" has become
different from "git commit --dry-run".

That is, "git commit --short/--porcelain/-z" has these three

 - work (ignoring these options);

 - work (showing the template in some kind of "short" format); or

 - error out (clearly indicating that we did *not* make a commit).

and what we currently do is closest to the last (but we do not say
we did not create a commit).  In the longer term for Git 2.0, we may
want to change it to do one of the former two.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to