Re: Feature request: Limit git-status reports to a directory

From: Wincent Colaiuta <win@wincent.com>
Date: Oct 25, 2007, 13:03 UTC
Message-ID: <445E2F73-709F-4A4A-8A16-0C9FF7D67D96@wincent.com>
In-Reply-To: <Pine.LNX.4.64.0710251050390.25221@racer.site>

El 25/10/2007, a las 11:55, Johannes Schindelin escribió:

Show 14 quoted lines

> Hi,
>
> On Thu, 25 Oct 2007, Yin Ping wrote:
>
>> On 10/25/07, Michel Marti <mma@objectxp.com> wrote:
>>
>> It's also painful for me. IMHO, the behaviour of "git-status" should
>> keep consistent with "git-diff" and "git-log" which allow for the  
>> path.
>
> I am not so sure.  In other SCMs, "git status" may be a way to do "git
> diff --name-only" or "git ls-files", but not in git.  Here, it  
> strictly
> means "what would be happening if I were to commit _right_ _now_?".

Yes, but there's no reason why the user shouldn't be able to scope that down to a specific path, just as they currently can for git-diff (as you point out):

> IMHO it is not asking users too much when you say "git diff ." is  
> for the
> current directory, and "git diff" is for the whole working tree.

Sometimes if you have a dirty tree with lots of modified files and potentially lots of things added to the index the output of git- status can be quite long, and perhaps all you want to know about is what is the status of *this* directory or *that* file rather than having to visually scan through the entire git-status output. Accepting path info would therefore be a nice usability improvement.

Allowing git-status to accept a path would be consistent with how other git commands (like git-diff) already work, and with other SCMs too. The user is expected to know that what's in the index is what will be committed, and that if he/she types "git-status foo" then he/ she may only be seeing a subset of what's staged in the index.

But the way git-status currently behaves when supplied path info is puzzling to say the least. As the man page says:

> "The command takes the same set of options as git-commit; it shows  
> what would be committed if the same options are given to git-commit."

This means that if you do try passing a path to git-status (as surely many newcomers have done), you'll see the combined result of what is already staged in the index *plus* what would happen if you git-added the path(s) that you passed on the command line. I'd argue that this is counter-intuitive, and I think that most would expect that the paths would serve as scope *limiters* rather than indicators that something should be *added* to the index.

To illustrate this, an example; just say you have git-status output like this:

# On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: foo/bar # modified: baz # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # NOTES no changes added to commit (use "git add" and/or "git commit -a")

And you type "git-status foo":

# Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: foo/bar # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: baz # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # NOTES

I understand why it works this way, and it's explained by the man page, but the behaviour is the very last thing I would expect.

Cheers, Wincent