Re: Fwd: git status options feature suggestion

On Thu, Oct 9, 2008 at 9:12 AM, Michael J Gruber
[off-list ref] wrote:
<snip>

A few radical suggestions might be:

1. make ls-files and diff --name-status use compatible letters

2. rename git commit -n to git commit -b (as in bypass), make git commit
-n do what's expected ("--dry-run", n as in duNNo yet)

Ouch.  Please not -b.  I guess I need to get my other suggestions
upstream if I want to avoid option conflicts like this...

3. rename git status to git commit -n

4. make git status generate git diff --name-status like output

I'd really prefer to be able to get staged vs. unstaged information
out of status.  And the single-letter output, like what cvs/svn/hg
have, is less descriptive here.  (Sure, git status could use some
cleanup IMO, but a word instead of a letter for modification status is
a usability improvement in git over those other systems for new VCS
users.)

(3+4)'. make git status -l generate git diff --name-status like output
(l as in status Letter) as an alternative to 3+4

That seems nicer.


And another radical suggestion (wasn't this brought up before too?):

5. Allow limiting the status output to a set of paths.  diff, log,
add, grep, etc. can all take a subdirectory name and limit their
operation to files recursively underneath that path, but git status
doesn't do so when you run 'git status DIR'.  I know why it currently
behaves as it does, but it sure seems like unnecessary UI
inconsistency.


Just my $0.02,
Elijah