Re: Commiting automatically (2)

From: Maaartin <grajcar1@seznam.cz>
Date: Dec 20, 2010, 05:46 UTC
Message-ID: <loom.20101220T062209-24@post.gmane.org>
In-Reply-To: <7vaak1ftin.fsf@alter.siamese.dyndns.org>

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

> Maaartin <grajcar1 <at> seznam.cz> writes:
> 
> > 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).

Show 9 quoted lines

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

Show 13 quoted lines

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