threads / discuss / 10454

Feature request: Limit git-status reports to a directory

Subject: Feature request: Limit git-status reports to a directory

## tl;dr

5 messages between Oct 24, 2007 and Oct 25, 2007.

replies: 4people: 4as markdown or json

Michel Marti· Oct 24, 2007, 22:01 UTC · lore

I am sometimes interested in only seeing the status for a specific directory (and its sub-directories), but git-status is no help in this case - passing a directory does some sort of "git-commit --dry-run". I first thought that this is a bug until I saw in the man-page that this is actually a feature...

What I would like to have is something like "git status --limit <path>" and the reported filenames should then be relative to the current directory for easier copy/pasting them to e.g. git-add, git-diff, etc.

Cheers,
- Michel
Yin Ping· Oct 25, 2007, 02:14 UTC · re: Michel Marti · lore

Re: Feature request: Limit git-status reports to a directory

On 10/25/07, Michel Marti <mma@objectxp.com> wrote:
Show 5 quoted lines
> I am sometimes interested in only seeing the status for a specific
> directory (and its sub-directories), but git-status is no help in this
> case - passing a directory does some sort of "git-commit --dry-run". I
> first thought that this is a bug until I saw in the man-page that this
> is actually a feature...

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.

Another point, It will be helpful to add a config item to change the default behaviour for 'git-diff" and "git-log". For example, 'diff.defaultcurrentpath=true' to let git only show difference in current directory instead of difference in top directory when typing 'git-diff'

Show 8 quoted lines
>
> - Michel
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- 
franky
Johannes Schindelin· Oct 25, 2007, 09:55 UTC · re: Yin Ping · lore

Re: Feature request: Limit git-status reports to a directory

Hi,
On Thu, 25 Oct 2007, Yin Ping wrote:
Show 9 quoted lines
> On 10/25/07, Michel Marti <mma@objectxp.com> wrote:
> > I am sometimes interested in only seeing the status for a specific 
> > directory (and its sub-directories), but git-status is no help in this 
> > case - passing a directory does some sort of "git-commit --dry-run". I 
> > first thought that this is a bug until I saw in the man-page that this 
> > is actually a feature...
>
> 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_?".

Show 5 quoted lines
> Another point, It will be helpful to add a config item to change the 
> default behaviour for 'git-diff" and "git-log". For example, 
> 'diff.defaultcurrentpath=true' to let git only show difference in 
> current directory instead of difference in top directory when typing 
> 'git-diff'

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.

Besides, we cannot really change the default behaviour, since some porcelains use "git log" (and certainly there are some which use "git diff", too). They would suffer from this unexpected -- and indeed inconsistent, since the setting can differ between repositories -- output.

Hth, Dscho

Wincent Colaiuta· Oct 25, 2007, 13:03 UTC · re: Johannes Schindelin · lore

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

Michel Marti· Oct 25, 2007, 13:03 UTC · re: Johannes Schindelin · lore

Re: Feature request: Limit git-status reports to a directory

on 10/25/2007 11:55 AM Johannes Schindelin said the following:
> 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_?".

I somehow agree with your argument, but then again, sometimes I'm still interested in *only* the status for a given directory.

IMHO, answering the question "what would be happening if...?" should be git-commit's task (e.g. git-commit --dry-run). And git-status should behave similar to git-log and git-diff.

For those interested: I have attached a little script that mimics current git-status (except the "dry-run" stuff) but also can take a list of directories/files.

#!/bin/sh

USAGE='[--staged] [--changed] [--untracked]' SUBDIRECTORY_OK=1 . git-sh-setup require_work_tree

print_stat_line() {
	case "$1" in
		M)	echo "#       modified:  $2";;
		A)	echo "#       new file:  $2";;
		R*)	echo "#       renamed:   $2 -> $3";;
		D)	echo "#       deleted:   $2";;
		U)	echo "#       unmerged:  $2";;
		X)	echo "#       $2";;
		*)	echo "#       [$S]:      $2";;
	esac
}
STAGED= CHANGED= UNTRACKED= HP=
while test $# != 0
do
	case "$1" in
		-s|--staged) STAGED=1; shift;;
		-c|--changed) CHANGED=1; shift;;
		-u|--untracked) UNTRACKED=1; shift;;
		--) shift; break;;
		-*) usage;;
		 *) break;;
	esac
done
if BRANCH_NAME=$(git symbolic-ref -q HEAD)
then
	BRANCH_NAME="On branch $(expr "z$BRANCH_NAME" : 'zrefs/heads/\(.*\)')"
else
	BRANCH_NAME="Not currently on any branch"
fi
[ "$#" = 0 ] && cd_to_toplevel
if [ -z "$STAGED$CHANGED$UNTRACKED" ]; then
	STAGED=1; CHANGED=1; UNTRACKED=1
fi
SP=$(echo _/$(git rev-parse --show-cdup)|tr '/' ' '|wc -w)
echo "# $BRANCH_NAME"
# Changes to be commited
[ "$STAGED" ] && git-diff --name-status --cached -M -- "$@"|while read S F R
do
	if [ -z "$HP" ]; then
		echo '# Changes to be committed:'
		echo '#   (use "git reset HEAD <file>..." to unstage)'
		echo '#'
		HP=1
	fi
	F=$(echo $F|cut -d'/' -f$SP-)
	print_stat_line "$S" "$F" "$R"
done
# Changed but not updated
[ "$CHANGED" ] && git-diff --name-status -- "$@"|while read S F
do
	if [ -z "$HP" ]; then
		echo '#'
		echo '# Changed but not updated:'
		echo '#   (use "git add <file>..." to update what will be committed)'
		echo '#'
		HP=1
	fi
	F=$(echo $F|cut -d'/' -f$SP-)
	print_stat_line "$S" "$F"
done
# Untracked files
[ "$UNTRACKED" ] && git-ls-files --exclude-per-directory=.gitignore -o --directory -- "$@"|while read F
do
	if [ -z "$HP" ]; then
		echo '#'
		echo '# Untracked files:'
		echo '#   (use "git add <file>..." to include in what will be committed)'
		echo '#'
		HP=1
	fi
	print_stat_line "X" "$F"
done

← back to recent threads