Re: Feature request: Limit git-status reports to a directory
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