"Sverre Rabbelier" <alturin@xxxxxxxxx> 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. -- 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
