All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Maaartin-1 <grajcar1@seznam.cz>
Cc: git@vger.kernel.org
Subject: Re: Commiting automatically (2)
Date: Mon, 27 Dec 2010 13:04:02 +0100	[thread overview]
Message-ID: <201012271304.03915.jnareb@gmail.com> (raw)
In-Reply-To: <4D1190A6.4070201@seznam.cz>

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

  parent reply	other threads:[~2010-12-27 12:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-19  8:29 Commiting automatically (2) Maaartin
2010-12-19 15:08 ` Taylor Hedberg
2010-12-19 18:36   ` Jonathan Nieder
2010-12-19 20:17     ` Jonathan Nieder
2010-12-20  5:12     ` Maaartin
2010-12-19 19:32 ` Junio C Hamano
2010-12-20  5:46   ` Maaartin
2010-12-20  7:33     ` Enrico Weigelt
2010-12-21  8:36       ` Maaartin
2010-12-21 13:06         ` Jakub Narebski
     [not found]           ` <4D1190A6.4070201@seznam.cz>
2010-12-27 12:04             ` Jakub Narebski [this message]
2011-01-03  0:39               ` Maaartin-1
2011-01-03 17:34                 ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201012271304.03915.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=grajcar1@seznam.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.