Re: Commiting automatically (2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]