Commiting automatically (2)

[Maaartin-1]

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jonathan Nieder-2]

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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Junio C Hamano]

Maaartin <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jonathan Nieder-2]

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

.)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Maaartin-1]

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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Maaartin-1]

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.




--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Enrico Weigelt]

* Maaartin <[hidden email]> 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:  [phone]  email: [hidden email]
 mobile: [phone]  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Maaartin-1]

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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narębski]

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

Maaartin <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narębski]

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 <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narębski]

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html