"Sverre Rabbelier" [off-list ref] writes:
... when I change files in the same directory I commit all
those in one go. As such I am a great fan of 'git diff .' and 'git
commit .'
The command in such a work flow for "What has been changed here" is not
"git status", but is "git diff <diff args> HEAD .", if "git commit ." is
how you make your commits. --name-status, --name-only or --stat may be
a good option to give in that command line.
As "git status" is a Porcelain just like "git commit" is, its output
format is not holy. It is not meant to be parsed by scripts and we are
free to change its behaviour for human users typing at it and reading from
it, provided if the change is worth making. However, for this particular
case, I doubt changing the existing "git status" that is a preview of the
next commit is necessary nor has much merit.
Not because I think your workflow is minority (I don't), but simply
because "git status" is not what you need in this case (you may think it
is what you "want", but notice that I said what you "need").
This is because "git status <paths>" these days is much less useful than
it was originally, after we made --only the default mode for "git commit".
It used to be that the default for "git commit" was --include. If you say
"git commit foo" when you have some changes already staged, the commit
will include what has already been staged plus the latest contents you
have in "foo". With such a system, "git status foo" _was_ a very useful
way to remind yourself what changes _other than_ you are naming from the
command line are going to be committed. It still is the default when you
are recording a merge commit, as the typical use case is that most of the
paths have already been resolved, you fixed up the conflicted ones in your
work tree, and you say "git commit <these I fixed up>". You do not want
to record a new commit that ignores what is staged in this case.
These days, --only is the default mode of operation. "git commit foo"
commits _only_ the changes made to what you named from the command line,
disregarding what you have already staged in the index so far. Because
you are already naming what you want to commit, the value in reminding
what others will also be committed, as there is none, has diminished
greatly, compared to the days when --include was the default. It still
has value that reminds you what you meant by the dot in "git commit ."
(which is essentially what "git diff --name-only HEAD ." is). It also
has value that reminds you what you may need/want to commit after making
this commit in this directory. But it has less information than the old
days, because you already know "what will be committed" will not include
what you did not name from the command line (in your _particular_ use
case, "the current directory"), and "what could be committed" will only
consists of the rest (in your _particular_ use case, "outside the current
directory").
We could special case and make it not report anything that will be left in
the work tree that is different from the resulting commit when --only is
in effect, which is what you seem to "want". But even that should not be
the default but be an option, as that mode is robbing from users (other
than yourself) the information "what other changes I may still need to
commit after this". But if you are going to give that option and say
"git status --commit-only ." there is already existing tool to ask the
question you are asking in a more direct way.
[Apologies for sending it twice, I keep forgetting to hit 'reply to
all' instead of 'reply']
On Sat, Apr 12, 2008 at 11:16 PM, Junio C Hamano [off-list ref] wrote:
"Sverre Rabbelier" [off-list ref] writes:
> ... when I change files in the same directory I commit all
quoted
those in one go. As such I am a great fan of 'git diff .' and 'git
> commit .'
The command in such a work flow for "What has been changed here" is not
"git status", but is "git diff <diff args> HEAD .", if "git commit ." is
how you make your commits. --name-status, --name-only or --stat may be
a good option to give in that command line.
That is nice indeed, I didn't use 'git diff' for that as it gave me
_too much_ information (the diff, whereas I'm only interested in
one-liners like those in '--name-status' (even --stat is too much).
As "git status" is a Porcelain just like "git commit" is, its output
format is not holy. It is not meant to be parsed by scripts and we are
free to change its behaviour for human users typing at it and reading from
it, provided if the change is worth making. However, for this particular
case, I doubt changing the existing "git status" that is a preview of the
next commit is necessary nor has much merit.
Ah, I didn't realize this but it does make sense now that you
explained it, thank you.
Not because I think your workflow is minority (I don't), but simply
because "git status" is not what you need in this case (you may think it
is what you "want", but notice that I said what you "need").
That is of course a possibility, it was more that since it's task is
"Show the working tree status" I thought it was what I need. I don't
mind using another command for what I need, although 'git diff
--name-status .' for example is a lot longer to type than 'git status
.'.
This is because "git status <paths>" these days is much less useful than
it was originally, after we made --only the default mode for "git commit".
It used to be that the default for "git commit" was --include. If you say
"git commit foo" when you have some changes already staged, the commit
will include what has already been staged plus the latest contents you
have in "foo". With such a system, "git status foo" _was_ a very useful
way to remind yourself what changes _other than_ you are naming from the
command line are going to be committed. It still is the default when you
are recording a merge commit, as the typical use case is that most of the
paths have already been resolved, you fixed up the conflicted ones in your
work tree, and you say "git commit <these I fixed up>". You do not want
to record a new commit that ignores what is staged in this case.
I didn't know about this previous behavior, the current situation
makes more sense after this little bit of history, sweet.
These days, --only is the default mode of operation. "git commit foo"
commits _only_ the changes made to what you named from the command line,
disregarding what you have already staged in the index so far. Because
you are already naming what you want to commit, the value in reminding
what others will also be committed, as there is none, has diminished
greatly, compared to the days when --include was the default. It still
has value that reminds you what you meant by the dot in "git commit ."
(which is essentially what "git diff --name-only HEAD ." is). It also
has value that reminds you what you may need/want to commit after making
this commit in this directory. But it has less information than the old
days, because you already know "what will be committed" will not include
what you did not name from the command line (in your _particular_ use
case, "the current directory"), and "what could be committed" will only
consists of the rest (in your _particular_ use case, "outside the current
directory").
I would agree, except that (after trying out just now), I noticed that
"git diff --name-only HEAD ." does not list new files. In my workflow
I am definitely interested in new files, is there a way to have 'git
diff --some-switch-here HEAD .' show those too?
We could special case and make it not report anything that will be left in
the work tree that is different from the resulting commit when --only is
in effect, which is what you seem to "want". But even that should not be
the default but be an option, as that mode is robbing from users (other
than yourself) the information "what other changes I may still need to
commit after this". But if you are going to give that option and say
"git status --commit-only ." there is already existing tool to ask the
question you are asking in a more direct way.
Well, it's not just 'git status .' that I would be interested in,
pretty much anything that reduces the size of 'git status' would be
useful indeed. Being able to limit the output of 'git status' (or 'git
diff --names-only', with whatever switch needed to make it show new
files) with an arbitrary filter is pretty much what I want. I
understand better now what other people use 'git status' for now, and
I agree that changing it's behavior in the way I described would mean
robbing them of information. Even so, I still think it makes more
sense to have that information in "git commit -d" but I guess that's
more personal preference than anything (plus I'm biased).
Thank you for your explanation,
Sverre