From: Maaartin <grajcar1@seznam•cz>
To: git@vger•kernel.org
Subject: Re: Commiting automatically (2)
Date: Mon, 20 Dec 2010 05:46:47 +0000 (UTC) [thread overview]
Message-ID: <loom.20101220T062209-24@post.gmane.org> (raw)
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).
> >
> > 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.
next prev parent reply other threads:[~2010-12-20 5:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-19 8:29 Commiting automatically (2) Maaartin
2010-12-19 15:08 ` Taylor Hedberg
2010-12-19 18:36 ` Jonathan Nieder
2010-12-19 20:17 ` Jonathan Nieder
2010-12-20 5:12 ` Maaartin
2010-12-19 19:32 ` Junio C Hamano
2010-12-20 5:46 ` Maaartin [this message]
2010-12-20 7:33 ` Enrico Weigelt
2010-12-21 8:36 ` Maaartin
2010-12-21 13:06 ` Jakub Narebski
[not found] ` <4D1190A6.4070201@seznam.cz>
2010-12-27 12:04 ` Jakub Narebski
2011-01-03 0:39 ` Maaartin-1
2011-01-03 17:34 ` Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20101220T062209-24@post.gmane.org \
--to=grajcar1@seznam$(echo .)cz \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox