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.
> 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.
> * 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.
> * 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html