Re: Fwd: git status options feature suggestion

From: Elijah Newren <newren@gmail.com>
Date: Oct 10, 2008, 04:25 UTC
Message-ID: <51419b2c0810092125w38c2eaffgc023cec207731a3e@mail.gmail.com>
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>

On Thu, Oct 9, 2008 at 9:12 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote: <snip>

Show 6 quoted lines

> 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