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

From: Jeff King <peff@peff.net>
Date: Aug 6, 2009, 16:42 UTC
Message-ID: <20090806164247.GA1073@coredump.intra.peff.net>
In-Reply-To: <7vljlwnc6j.fsf_-_@alter.siamese.dyndns.org>

On Thu, Aug 06, 2009 at 09:23:48AM -0700, Junio C Hamano wrote:

> 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).

If the output format is the only change, then that probably makes sense, but I think there is a desire for a command that is more substantially different.

Show 10 quoted lines

> 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.

That makes sense.

Show 10 quoted lines

>  * 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.

I wonder if introducing such a configuration option is not going to cause more confusion in the long run than simply switching. As a script-writer, you are not helping me at all because I can't make any assumptions about how the user has set the variable.

I guess you are helping those who want to keep "git status" as-is forever for their own typing. I'm not sure that such people exist, but I guess it is better to be conservative.

Show 9 quoted lines

>  * 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".

Makes sense.

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

It may make sense to do it anyway, just to give a playground for people to try out and refine the new interface. In other words, do:

  - introduce shortstatus (or newstatus, or whatever you want to call
    it)

  - wait a few cycles for it to prove itself

  - proceed with transition plan you described above

  - explain transition as "status is now newstatus, old status is now
    commit --dry-run".

-Peff