threads / discuss / 22939

Re: Determining if a tree is clean

Subject: Re: Determining if a tree is clean

## tl;dr

3 messages between Mar 6, 2010 and Mar 6, 2010.

replies: 2people: 2as markdown or json

Adam Mercer· Mar 6, 2010, 15:12 UTC · lore

Determining if a tree is clean

Hi

In one of the projects I work in we have a script which creates a header file containing various commit information, such as the id of the HEAD commit, the date it was committed, who made the commit, and if the tree is clean (i.e. no uncommitted changes). In order to determine if the tree is clean we use the command

git diff-index --quiet HEAD

and if the this exits with a non-zero return code then we assume that the tree is unclean. However I have found a case when this exits with a return code of 1 when the tree has no uncommitted changes, e.g.:

$ git diff-index --quiet HEAD $ echo $? 1 $

and when I look at what file it thinks is unclean I get:

$ git diff-index HEAD :100644 100644 3b839718d3f182119db5d9e2b88e516e02ecc00b 0000000000000000000000000000000000000000 M lal/include/lal/LALConfig.h.in $ git diff-index -p HEAD

diff --git a/lal/include/lal/LALConfig.h.in b/lal/include/lal/LALConfig.h.in
$

which shows no changes in the actual file. This file is the template
for a header created using the AC_CONFIG_HEADERS() autoconf macro.
From the above it looks like the build process has created a new file
with exactly the same contents as the file specifies in the index. Is
there a way that I can tell git-diff-index that this is OK? Or is
there another way I can determine if the tree has any uncommitted
changes?

I'm seeing this with git-1.7, on Mac OS X 10.6, and git-1.5.5.6, on RHEL5.

Cheers

Adam

Junio C Hamano· Mar 6, 2010, 19:23 UTC · re: Adam Mercer · lore

Adam Mercer <ramercer@gmail.com> writes:

> git diff-index --quiet HEAD

It is expected that a Porcelain script that implements a custom feature may call diff-files, diff-index and other plumbing commands many times during its lifetime, and that it knows what it is doing (namely, when it touches the working tree itself and why).

For this reason, most plumbing commands do not refresh the cached stat information in the index. A Porcelain script is responsible for running "update-index --refresh" once before it makes a call that cached stat information matters, and as long as it doesn't touch the files in the working tree, it doesn't have to run it again and again.

Porcelain commands like "git diff" that are expected to be run directly by the end user cannot assume that, so they do not optimize---they typically refresh the cached stat information by themselves internally whey they start up.

Your Porcelain script should look something like:

    git update-index --refresh
    git diff-files -q || { echo "modified working tree"; exit 1 }
    git diff-index --cached -q HEAD || { echo "modified index"; exit 2 }

See contrib/examples/*.sh for examples.

Adam Mercer· Mar 6, 2010, 20:33 UTC · re: Junio C Hamano · lore

On Sat, Mar 6, 2010 at 13:23, Junio C Hamano <gitster@pobox.com> wrote:

> It is expected that a Porcelain script that implements a custom feature
> may call diff-files, diff-index and other plumbing commands many times
> during its lifetime, and that it knows what it is doing (namely, when
> it touches the working tree itself and why).

Makes sense.

Show 7 quoted lines

> Your Porcelain script should look something like:
>
>    git update-index --refresh
>    git diff-files -q || { echo "modified working tree"; exit 1 }
>    git diff-index --cached -q HEAD || { echo "modified index"; exit 2 }
>
> See contrib/examples/*.sh for examples

Thanks, Junio. That does the trick, I'd recently found the update-index command and had run into the problem (but not the solution) that the call to diff-files addresses.

Cheers

Adam