Breaking "git status" (was Re: [PATCH 5/5] shortstatus: a new command)

Jeff King <peff@peff.net> writes:

As I said, this was more of technology demonstration with an iffy UI.

I've been wondering if this should be "git status -T" (a la "ls-files -t", but nice short-and-sweet -t is taken for rarely used --template).

For that matter, as 1.7.0 material that potentially breaks backward compatibility in a big way, it is tempting to suggest that we might want to depart from the traditional "status takes the same parameters to commit and gives a preview of what would happen" semantics. Even though the current "status" takes the same set of parameters as "commit" takes, many of the parameters, especially the ones related to message generation, do not make sense.

Here is a possible transition plan. I am not married to it, but throwing it out as a discussion starter:

 * Introduce "git commit --dry-run", that takes place of the current
   "git status".

   We will keep "git commit --dry-run" forever so that people can simply
   do a "s/git status/git commit --dry-run/" to keep their own scripts
   that currently run "git status" before deciding to run "git commit" (or
   runs their own re-implementation of "git commit") working.

 * Introduce "status.traditional" configuration.  In 1.6.5

   - When set to true, "git status" behaves as "git commit --dry-run";

   - When set to false, "git status" uses a new semantics (TBD);

   - When unconfigured, the user gets a big incompatibility warning.

   and in 1.7.0, we will flip the default (i.e. unconfigured case) to
   false.

 * Implement "git status" that is not a preview of "git commit".  Its new
   semantics would include:

   - Reject any parameter that traditional "git status" ignored (i.e. -m);

   - Pathspecs are not about "git commit -o" anymore.  They are path
     limiters.

   - One of the options, -t, gives the "shortstatus".

If we go a route like this, we do not want to add "shortstatus" as a standalone command.