git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, jrnieder@gmail.com
Subject: Re: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames
Date: Mon, 13 May 2013 08:31:23 +0200	[thread overview]
Message-ID: <CALKQrgf0m8r-Ofb+Ss1OpEF67dPS73b8nB+usVxH=Y=h3441Wg@mail.gmail.com> (raw)
In-Reply-To: <7vmwrzsck1.fsf@alter.siamese.dyndns.org>

On Mon, May 13, 2013 at 6:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:
>
>> The refname_expand() function no longer uses mkpath()/mksnpath() to
>> perform the pattern expansion. Instead, it uses strbuf_expand(), which
>> removes the need for using fixed-length buffers from the code.
>
> It is a brilliant idea to use strbuf_expand() for this. I like it.
>
> I notice that you later introduce %1 (that is 'one', not 'el'), but
> unless you are planning to introduce %2 and %3 that semantically
> fall into a similar category as %1, I would rather see a different
> letter used that is mnemonic to what the placeholder _means_.
>
> The choice of the letter is arbitrary and may not look like it
> matters that much, because it is not exposed to the end user.  But
> by switching from the sprintf() semantics that shows things given to
> it in the order they were given, without knowing what they mean, and
> introducing a strbuf_expand() machinery tailored for refnames (and
> refnames only), the new code assigns meanings to each part of the
> refname, and we can afford to be more descriptive.
>
> The choice of '%*' is justifiable, "it is the closest to the '*' we
> traditionally used to replace only one thing", but '%1' does not
> look the best placeholder to use, at least to me.

Obviously, I named it '%1' since it expands into the _first_ component
of the (slash-separated) shorthand. There is no further parsing or
verification that it actually corresponds to a remote (and as far as I
currently understand, we do not want to do such verification), so I
thought it better not to make such assumptions in the placeholder
name. That said, I could go with '%r' for "remote", although we have
plenty of other concepts in Git that use 'r' as the initial letter. I
could maybe use '%remote' instead?

Also, about the '%*': When used alone, it means "the entire
shorthand", but when preceded with a '%1' it subtly changes meaning
into 'the remainder of the shorthand after extracting the first
component'. I believe the two interpretations are compatible and
unambiguous, but if we want to be very explicit about what's
happening, we could use something like '%all' and '%the_rest' for the
two cases, respectively?


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

  reply	other threads:[~2013-05-13  6:31 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-11 16:21 [PATCHv2 00/10] Prepare for alternative remote-tracking branch location Johan Herland
2013-05-11 16:21 ` [PATCHv2 01/10] t7900: Start testing usability of namespaced remote refs Johan Herland
2013-05-11 16:21 ` [PATCHv2 02/10] t7900: Demonstrate failure to expand "$peer/$branch" according to refspecs Johan Herland
2013-05-11 16:21 ` [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames Johan Herland
2013-05-13  4:56   ` Junio C Hamano
2013-05-13  6:31     ` Johan Herland [this message]
2013-05-13  6:45       ` Junio C Hamano
2013-05-13 20:34         ` Junio C Hamano
2013-05-14 14:24           ` Johan Herland
2013-05-14 17:50             ` Junio C Hamano
2013-05-15  6:45             ` Michael Haggerty
2013-05-15  7:39               ` Johan Herland
2013-05-15 13:53                 ` Johan Herland
2013-05-15 15:14                   ` Junio C Hamano
2013-05-15 19:49                   ` Eric Wong
2013-05-11 16:21 ` [PATCHv2 04/10] remote: Reject remote names containing '/' Johan Herland
2013-05-13  4:48   ` Eric Sunshine
2013-05-13  6:32     ` Johan Herland
2013-05-13  4:54   ` Junio C Hamano
2013-05-13  6:53     ` Johan Herland
2013-05-16  9:48       ` Ramkumar Ramachandra
2013-05-16 11:17         ` Johan Herland
2013-05-16 12:14           ` Ramkumar Ramachandra
2013-05-11 16:21 ` [PATCHv2 05/10] refs.c: Add support for expanding/shortening refs in refs/peers/* Johan Herland
2013-05-11 16:21 ` [PATCHv2 06/10] t7900: Test git branch -r/-a output w/remote-tracking branches " Johan Herland
2013-05-11 16:21 ` [PATCHv2 07/10] t3203: Add testcase for fix in 1603ade81352a526ccb206f41ff81ecbc855df2d Johan Herland
2013-05-11 16:21 ` [PATCHv2 08/10] builtin/branch.c: Refactor ref_item.name and .dest into strbufs Johan Herland
2013-05-11 16:21 ` [PATCHv2 09/10] builtin/branch.c: Refactor "remotes/" prepending to remote-tracking branches Johan Herland
2013-05-11 16:21 ` [PATCHv2 10/10] branch: Fix display of remote branches in refs/peers/* Johan Herland
2013-05-13  5:19   ` Eric Sunshine
2013-05-13  6:55     ` Johan Herland

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='CALKQrgf0m8r-Ofb+Ss1OpEF67dPS73b8nB+usVxH=Y=h3441Wg@mail.gmail.com' \
    --to=johan@herland.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).