When working directory and index are clean, nothing happens when git-stash
is run. If ran under fakeroot (in debian/rules for example) on the same tree,
git-stash makes an empty commit, and consumes a large amount of time
saving and checking out the files in the repository, which is rather annoying
and litters the repository with unnecessary commits.

An example:

$ git stash
No local changes to save
$ fakeroot git stash
Saved working directory and index state "WIP on master: a1dc649... test"
(To restore them type "git stash apply")
HEAD is now at a1dc649... test

Teemu

It's 'git diff-files' vs 'fakeroot git diff-files'.

Hi Teemu, I can reproduce this.  It's actually git diff-files, which is
utilized by git-stash; 'git diff-files' vs 'fakeroot git diff-files'.

Regards, Gerrit.

clone 472331 -1
retitle -1 git-diff-files: Need to refresh index undocumented
severity -1 minor
fixed 472331 1:1.6.0.2-1
thanks

Teemu Ikonen wrote:
deciding if the work tree is dirty", included in upstream release
1.6.0.2.

Gerrit Pape wrote:

This behavior seems to be intentional, but it is not documented. I
can't seem to write reasonable documentation at this hour, so no patch
yet, but here are some pointers so I don't forget.

 * <http://article.gmane.org/gmane.comp.version-control.git/94651> and
the rest of the thread explain the philosophy. Scripts are supposed to
run "update-index --refresh" in advance themselves.

 * The second-to-last NOTE in git-diff-index(1) describes similar behavior.

 * Maybe git-diff-files(1) should just defer to git-diff-index(1) for
documentation (e.g. "like diff-index's default mode, but compares the
working copy to the index instead of to a named tree object").

Regards,
Jonathan