Re: Commiting automatically (2)

From: Maaartin-1 <grajcar1@seznam.cz>
Date: Jan 3, 2011, 00:39 UTC
Message-ID: <4D211AA4.4050108@seznam.cz>
In-Reply-To: <201012271304.03915.jnareb@gmail.com>

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

Show 19 quoted lines

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

Show 5 quoted lines

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

Show 13 quoted lines

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

Show 6 quoted lines

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