[RFC] git status oddity

Heya,

I have a directory structure that groups files together in such a way that usually 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 .' because they allow me to make such partial commits. Sadly, 'git status' does not play along well with this workflow. What I would expect is 'git status .' to return changes made in the current directory. More general, I expect 'git status <filter>' to perform it's magic on only the files that match the filter. What I deduct from the man page however, 'git status' is merely a 'dry run' of git commit. While this make sense when using it as part of git commit (to generate a commit msg), it does not make a lot of sense when using it as a first-class citizen.

I suggest changing this behavior to be more intuitive (e.g., matching 'git diff' and 'git commit's filtering behavior). As a result commands that assume 'git status' is a dry run of 'git commit' would have to be changed to pass an additional argument to 'git status' to tell it to perform it's old behavior. Even better, a '-d' (for --dry-run) switch could be added to 'git commit' which would make it act as 'git status' does currently.

Proposed:
1. Add a '-d'/'--dry-run' switch to 'git commit' which makes it behave
as 'git status' does currently
2. Improve git status to instead take a path argument on which it will
filter it's output.
3. From here on additional improvements to 'git status' can be made
without having to worry about breaking 'git commit' dry-run capability
since that functionality has been put where it belongs, that is, in
'git commit -d'.

This would break programs and scripts that assume 'git status' is a dry-run of 'git commit', as such I realize this would probably not be integrated anytime soon. Also, I would like to know whether the community agrees that current 'git status' behavior does not make sense when using it as a first-class citizen. Of course, I assume here that 'git status' is indeed a first-class citizen, if this assumption is wrong please explain why.

Below is a trivial workflow example.

ubuntu@ubuntu:~/code/StatusExample$ git init
Initialized empty Git repository in .git/
ubuntu@ubuntu:~/code/StatusExample$ mkdir dir1 dir2
ubuntu@ubuntu:~/code/StatusExample$ touch dir1/foo dir1/bar dir2/foobar
ubuntu@ubuntu:~/code/StatusExample$ git add .
ubuntu@ubuntu:~/code/StatusExample$ git commit -m "Initial"
Created initial commit 35dc187: Initial
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 dir1/bar
 create mode 100644 dir1/foo
 create mode 100644 dir2/foobar
ubuntu@ubuntu:~/code/StatusExample$ echo "1" >> dir1/foo
ubuntu@ubuntu:~/code/StatusExample$ echo "2" >> dir1/bar
ubuntu@ubuntu:~/code/StatusExample$ echo "3" >> dir2/foobar
ubuntu@ubuntu:~/code/StatusExample$ cd dir1/
ubuntu@ubuntu:~/code/StatusExample/dir1$ git status .
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   dir1/bar
#       modified:   dir1/foo
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   dir2/foobar
#

The above result would be the output of 'git commit -d .' Expected output: # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: dir1/bar # modified: dir1/foo #

Thank you for your time,

Sverre Rabbelier