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 "--dry-run". 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 possibilities: - 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
