Commiting automatically (2)

Commiting automatically (2)

[Maaartin]

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

Re: Commiting automatically (2)

[Taylor Hedberg]

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.

Re: Commiting automatically (2)

[Jonathan Nieder]

Taylor Hedberg wrote:
> 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.

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?

Re: Commiting automatically (2)

[Jonathan Nieder]

Jonathan Nieder wrote:
>> 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.
[...]
> 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

.)

Re: Commiting automatically (2)

[Maaartin]

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.

Re: Commiting automatically (2)

[Junio C Hamano]

Maaartin <grajcar1@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?

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.

Re: Commiting automatically (2)

[Maaartin]

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.

Re: Commiting automatically (2)

[Enrico Weigelt]

* Maaartin <grajcar1@seznam.cz> wrote:

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

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, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Commiting automatically (2)

[Maaartin]

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

> * Maaartin <grajcar1 <at> seznam.cz> wrote:
> 
> > 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.
> 
> 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.

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.

Re: Commiting automatically (2)

[Jakub Narebski]

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

Maaartin <grajcar1@seznam.cz> writes:

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

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.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Commiting automatically (2)

[Jakub Narebski]

On Wed, 22 Dec 2010, Maaartin-1 wrote:
> On 10-12-21 14:06, Jakub Narebski wrote:
>>
>> Please try to not cull Cc list (use 'reply via email', if possible)
> 
> I don't know what "cull" means and
> http://dictionary.reference.com/browse/cull
> doesn't help me at all. Could you explain?

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.

>> Maaartin <grajcar1@seznam.cz> writes:
>> 
>>> 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.
[...]
>> 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/`.
> 
> IMHO, it's quite broken. Alone it would be fine, but should really
> git-show-ref behave that different from git-symbolic-ref?

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.

> Moreover, git-show-ref --head shows all branches and tags, this can't be
> right, can it? According to your above explanation, getting HEAD using a
> pattern is impossible, so I'd say that's what is "--head" good for.
> 
> Moreover, "git-show-ref --heads" shows less than "git-show-ref --head",
> despite the plural.

"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 tripped over strange git-show-ref <pattern> semantic too.
>> 
>> P.S. there is also git-for-each-ref.

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

-- 
Jakub Narebski
Poland

Re: Commiting automatically (2)

[Maaartin-1]

On 10-12-27 13:04, Jakub Narebski wrote:
> On Wed, 22 Dec 2010, Maaartin-1 wrote:
>> On 10-12-21 14:06, Jakub Narebski wrote:
>>>
>>> Please try to not cull Cc list (use 'reply via email', if possible)
>>
>> I don't know what "cull" means and
>> http://dictionary.reference.com/browse/cull
>> doesn't help me at all. Could you explain?
> 
> 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.

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.

>> IMHO, it's quite broken. Alone it would be fine, but should really
>> git-show-ref behave that different from git-symbolic-ref?
> 
> git-symbolic-ref is about querying and manipulating _single_ symbolic
> reference, using fully qualified branch names (ref names).

OK, this is a sort of acceptable.

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

OK, the strange pattern matching is not that bad.

>> Moreover, git-show-ref --head shows all branches and tags, this can't be
>> right, can it? According to your above explanation, getting HEAD using a
>> pattern is impossible, so I'd say that's what is "--head" good for.
>>
>> Moreover, "git-show-ref --heads" shows less than "git-show-ref --head",
>> despite the plural.
> 
> "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 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 tripped over strange git-show-ref <pattern> semantic too.
>>>
>>> P.S. there is also git-for-each-ref.
> 
> 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...

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

Re: Commiting automatically (2)

[Jakub Narebski]

On Mon, 3 Jan 2011, Maaartin-1 wrote:
> On 10-12-27 13:04, Jakub Narebski wrote:
>> On Wed, 22 Dec 2010, Maaartin-1 wrote:

>>> Moreover, git-show-ref --head shows all branches and tags, this can't be
>>> right, can it? According to your above explanation, getting HEAD using a
>>> pattern is impossible, so I'd say that's what is "--head" good for.
>>>
>>> Moreover, "git-show-ref --heads" shows less than "git-show-ref --head",
>>> despite the plural.
>> 
>> "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 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?

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

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

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.

> 
>>>> I tripped over strange git-show-ref <pattern> semantic too.
>>>>
>>>> P.S. there is also git-for-each-ref.
>> 
>> 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...
> 
> I guess, I can get the single line I wanted using
> git for-each-ref $(git symbolic-ref HEAD)
> right?

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.

-- 
Jakub Narebski
Poland