Re: Why is there no git-update-cache --modified (aka I give up)

From: Junio C Hamano <junkio@cox.net>
Date: Jul 12, 2005, 08:14 UTC
Message-ID: <7v7jfwbfvj.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050712055218.GA18192@buici.com>

Marc Singer <elf@buici.com> writes:

Show 6 quoted lines

>   # 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 diff-cache.

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
		;;
	esac
	git-update-cache --refresh >/dev/null
	git-diff-files |
        sed -e 's/.*	//' |
	xargs -r git-update-cache --add --remove --

[Footnote]

*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.