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:

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

Taylor Hedberg wrote:

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:

[...]

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:

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.

Maaartin <grajcar1@seznam.cz> writes:

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?

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

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.

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

deleted. 

strongly 

files).

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

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.

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

* Maaartin <grajcar1@seznam.cz> wrote:

Perhaps it's wise to just use a separate repository on the same repository. Maybe make it more convenient using some little shell functions. I'm also using that for backup purposes, where the repo lies outside the to-be-backed-up tree.

cu

Enrico Weigelt <weigelt <at> metux.de> writes:

I considered using a separate repository, too, but having "all in one" feels somehow better. It allows me to push everything to a single remote repo and compare the snapshots to ordinal commits, etc.

I let the snapshot point to the current head, which is where I get a problem now: git show-ref HEAD returns nothing, git show-ref --head returns HEAD and all branches and tags. Isn't it a bug? How can I get the HEAD reference? I'm using git version 1.7.2.3 on cygwin.

Please try to not cull Cc list (use 'reply via email', if possible)

Maaartin <grajcar1@seznam.cz> writes:

You can use `git rev-parse --verify HEAD`, for example. Generally scripted commands (including those in contrib/examples/) are good sources of inspiration. Or if you want symbolic name, you can use `git symbolic-ref HEAD` or `git rev-parse --symbolic-full-name HEAD`.

As for `git show-ref HEAD` - git-show-ref uses its own way of pattern matching; in new enough version of git-show-ref manpage you can read that:

  <pattern>...::

        Show references matching one or more patterns. Patterns are matched from
        the end of the full name, and only complete parts are matched, e.g.
        'master' matches 'refs/heads/master', 'refs/remotes/origin/master',
        'refs/tags/jedi/master' but not 'refs/heads/mymaster' nor
        'refs/remotes/master/jedi'.

So `git show-ref HEAD` would match 'refs/.../HEAD`, e.g. `refs/remotes/origin/HEAD`, but not `HEAD` which is outside `refs/`.

I tripped over strange git-show-ref <pattern> semantic too.

P.S. there is also git-for-each-ref.

On Wed, 22 Dec 2010, Maaartin-1 wrote:

http://en.wiktionary.org/wiki/cull

  to cull
  [...]
  3. To select animals from a group and then kill them in order to
     reduce the numbers of the group in a controlled manner.

In the context ("to cull Cc list") it means removing entries from Cc list (courtesy copy, copy-to), i.e. not replying to all people participating in given (sub)thread.

[...]

git-symbolic-ref is about querying and manipulating _single_ symbolic reference, using fully qualified branch names (ref names).

git-show-ref is about querying multiple refs; I think the design goal behind its strange pattern matching semantic is to make it easy to get all refs with the same short name.

"git show-ref --head" is strange in that it doesn't play well with '--heads' and '--tags' and '<pattern>'.

I think it is a bit of misdesign, but I don't know how it should be fixed; current output of "git show-ref --head" has to be kept because of backward compatibility - git-show-ref is plumbing.

I don't know why there is git-show-ref when we have git-for-each-ref for scripting; I guess they were added nearly at the same time...

On 10-12-27 13:04, Jakub Narebski wrote:

I was using the gmane page, which did it. Next time I replied using email, but forgot to add the CC. There are things I hate more than mailing lists, but they're fairly rare.

OK, this is a sort of acceptable.

OK, the strange pattern matching is not that bad.

I wonder what git show-ref --head really does. It seems to output everything, is this the expected (albeit strange) behavior? Maybe, I know now, s. below.

For sure, either the doc is completely wrong or the implementation. I hope I understand "Show the HEAD reference" correctly as showing the HEAD reference, don't I? So it must show a single reference (singular). Instead I get all tags and all heads. Could anybody either fix the doc or convince me that the many lines I'm seeing are a single one?

Shouldn't there be an option *really* doing what --head is expected and documented to do? I mean something like git show-ref --head --yes-I-really-mean-the-head with the output consisting of a single line like 4ba2b422cf3cc229d894bb31c429c0c588de85c0 HEAD Maybe it could be called --head-only.

It could help a lot to add the word "additionally" to the doc like --head Additionally show the HEAD reference.

I guess, I can get the single line I wanted using git for-each-ref $(git symbolic-ref HEAD) right?

On Mon, 3 Jan 2011, Maaartin-1 wrote:

Well, it might be that *both* documentation and implementation are wrong.

Well, actually it doesn't do that. If '--head' is *alone* ref selector (e.g. "git show-ref --head") it shows HEAD reference in addition to all other refs (e.g. what "git show-ref" would show). But it doesn't seem to work in described way when combined with any of ref specifiers; neither "git show-ref --head --heads" not "git show-ref --head master" work as one would expect.

Well, both git-show-ref and git-for-each-ref are meant for checking or viewing multiple refs at once. If you are working with a single ref, then git-rev-parse (e.g. "git rev-parse --symboolic HEAD" or "git rev-parse --symbolic-full-name HEAD") or git-symbolic-ref would be a better choice IMHO.