Marc Singer <[EMAIL PROTECTED]> writes:

>   # git-diff-cache HEAD
> is really nice.  But, do I really have to invoke git-update-cache with
> every modified file?  I could write a script to cul the filenames from
> git-diff-cache, but I'm having a hard time believing that that is how
> others are preparing their commits.

Me too.  By the way, I think you mean diff-files not

I'd like to know how others do it, since this was the
first thing I automated when I started using GIT.  Having clear
distinction between cache (aka index file) and work tree files
and making user concious decision of when to and when not to
register/update index is what is quite different in GIT from
CVS, SVN and friends [*1*], and while I appreciate its
flexibility, it often ends up to be simply more typing (and to
certain degree more thinking which is not a bad thing) to the
user [*2*].

This snippet is essentially what I do to match the cache with
the current work tree [*3*]:

        case "$(git-ls-files --unmerged | sed -e 1q)" in
                echo >&2 You have unmerged files and cannot commit.
                exit 1
        git-update-cache --refresh >/dev/null
        git-diff-files |
        sed -e 's/.*    //' |
        xargs -r git-update-cache --add --remove --


*1* I vaguely recall reading somewhere that GIT is not the first
SCM to have these three (not two) levels.  Usual two-level SCM
needs to only move between your hackery and what's in the repo,
and words like "committing" and "checking in" are used
interchangeably, while the other three level SCM (I do not
remember which one I read about) gives distinct meaning to these
two words.  Can anybody tell me which SCM I am talking about?

*2* The commit flow in GIT is three level thing.  You have HEAD
version (a commit with an associated tree already in the object
database that you have checked out and started with), you have
cache, and you have files in your work tree.  Checking out is to
match cache and work tree to HEAD; update-cache is to match
cache to work tree; and committing is to create a new commit
that matches the cache and make it your HEAD.  Roughly speaking,
diff-* brothers are about comparing these three stages:

 - diff-files compares cache and work tree
 - diff-cache compares commit and cache, or commit and work tree
 - diff-tree compares two commits

*3* I do not officially do Porcelain ;-), but the script I use
is slightly different from the one quoted above.  It uses
"git-diff-files -z" and a helper program to handle filenames
with TAB in them.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to