Re: Commiting automatically (2)

Junio C Hamano <gitster <at> pobox.com> writes:

Maaartin <grajcar1 <at> seznam.cz> writes:

quoted

However, when I use my git-autocom script, those files get marked as 

deleted. 

quoted

This is quite strange, especially because of them still existing. I'd 

strongly 

quoted

prefer git-autocom to behave just like git commit (i.e., tracking the 

files).

quoted

The relevant part of my script follows:

export GIT_INDEX_FILE=.git/autocom.tmp
git add -A &&

If you really want "just like commit", then it would be more like "make a
commit object out of the current index, and put that somewhere outside the
current branch", and will not involve any "git add", no?

You're right, I was using the wrong term, what I wanted was to take a SNAPSHOT 
of the current working dir (this is called "commit" in csv/svn but not in git, 
I know).

A useful goal would be "as if I said 'git add -u && git commit' from the
current state" (alternatively, you could say s/-u/-A/).

Yes, I wonder why it wasn't already implemented. I do something like
make all; git snapshot; send_the_executable_to_the_customer
which is IMHO needed quite often.

If this autocom.tmp starts out empty, "add" will of course honor what you
wrote in .gitignore hence would not add ignored files.  You may have '*.o'
in the ignore mechanism to exclude usual build products.  Until you
somehow tell git that you care about a vendor-supplied binary blob file
"binblob1.o" even though it has a name for usual ignored ones, you don't
want to get it tracked, and once you have done so with "git add -f", you
do want to get it tracked from that point.  But your script cannot be
clever enough to selectively say "add -f" for such a file.

The "from the current state" part of the sentence of your goal (clarified
by the second paragraph above) fundamentally means you need to start from
your real index, so "cp -p .git/index $TMP_INDEX" is both appropriate and
inevitable for your script.

Now it's clear, thank you for the explanation.