Commiting automatically (2)

Some time ago I asked how to make a commit of the working tree in a way 
influencing neither the current branch nor the index:
http://comments.gmane.org/gmane.comp.version-control.git/157056
I'm going to use it for taking a snapshot of the current working tree without 
disturbing my work. It seem to work except for one thing:

There are files tracked by git and later added to .gitignore. AFAIK listing 
them in .gitignore is a no-op, since I haven't removed them from the index. 
Until now I haven't known about them at all, I'm currently undecided what to do 
to them.

However, when I use my git-autocom script, those files get marked as deleted. 
This is quite strange, especially because of them still existing. I'd strongly 
prefer git-autocom to behave just like git commit (i.e., tracking the files).

The relevant part of my script follows:

export GIT_INDEX_FILE=.git/autocom.tmp
git add -A &&
tree=$(git write-tree) &&
commit=$(echo "$message" | git commit-tree $tree $parent1 $parent2) &&
git update-ref -m "$message" refs/heads/autocom $commit

I'd say using another index is the reason for this behavior. The index gets 
created on the first use, which is probably why those files look like being 
deleted. Should I always
/bin/cp .git/index $GIT_INDEX_FILE
or is there a better way?

There's one more problem. My script doesn't recognize deleted files, since
git add -A
does nothing to them. I'm quite sure I saw a solution to this, but can't find 
it now...

On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:

There's one more problem. My script doesn't recognize deleted files, since
git add -A
does nothing to them. I'm quite sure I saw a solution to this, but can't find 
it now...

I believe "git add -u" will do the same thing as "git add -A", plus
handle deleted files.

Taylor Hedberg wrote:

On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:

quoted

There's one more problem. My script doesn't recognize deleted files, since
git add -A
does nothing to them. I'm quite sure I saw a solution to this, but can't find 
it now...

I believe "git add -u" will do the same thing as "git add -A", plus
handle deleted files.

Hmm, the "git add" manual suggests it is the other way around:

 -A, --all
	Like -u, but match <filepattern> against files in the working
	tree in addition to the index. That means that it will find new
	files as well as staging modified content and removing files
	that are no longer in the working tree.

So I would expect "git add -A" to do the same thing as "git add -u",
plus handling added files.

Maaartin, could you give an example showing where add -A goes wrong?

Jonathan Nieder wrote:

quoted

On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:

quoted

quoted

There's one more problem. My script doesn't recognize deleted files, since
git add -A
does nothing to them.

[...]

Maaartin, could you give an example showing where add -A goes wrong?

Please ignore; looks like Taylor and Junio figured it out.  (For
anyone else who was confused like me: the files in question were
removed with the equivalent of

	git rm --cached generated.c

rather than

	rm -f irrelevant.c

.)

Jonathan Nieder <jrnieder <at> gmail.com> writes:

Hmm, the "git add" manual suggests it is the other way around:

 -A, --all
	Like -u, but match <filepattern> against files in the working
	tree in addition to the index. That means that it will find new
	files as well as staging modified content and removing files
	that are no longer in the working tree.

So I would expect "git add -A" to do the same thing as "git add -u",
plus handling added files.

Maaartin, could you give an example showing where add -A goes wrong?

I can't, since I was wrong. These commits have two parents (I'm not sure if this 
is a good idea), and that's why I saw no changes in the log. Actually, "git add -
A" does everything I need, and with "/bin/cp .git/index $GIT_INDEX_FILE" 
everything seems to work. Sorry for the noise.