El 25/10/2007, a las 11:55, Johannes Schindelin escribió:
Hi,
On Thu, 25 Oct 2007, Yin Ping wrote:
On 10/25/07, Michel Marti <mma@xxxxxxxxxxxx> 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
-
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
