git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	Karthik Nayak <karthik.188@gmail.com>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [PATCH 4/8] interpret_branch_name: allow callers to restrict expansions
Date: Tue, 28 Feb 2017 16:37:26 -0500	[thread overview]
Message-ID: <20170228213726.3gvwomlpn2ukdcfl@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqr32ijc1q.fsf@gitster.mtv.corp.google.com>

On Tue, Feb 28, 2017 at 12:27:45PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > The original purpose of interpret_branch_name() was to be used by
> > get_sha1() in resolving refs.  As such, some of its expansions may
> > point to refs outside of the local "refs/heads" namespace.
> 
> I am not sure the reference to "get_sha1()" is entirely correct.
> 
> Until it was renamed at 431b1969fc ("Rename interpret/substitute
> nth_last_branch functions", 2009-03-21), the function was called
> interpret_nth_last_branch() which was originally introduced for the
> name, not sha1, at ae5a6c3684 ("checkout: implement "@{-N}" shortcut
> name for N-th last branch", 2009-01-17).  The use of the same syntax
> and function for the object name came a bit later.
> 
> But I think that is an insignificant detail.  Let's read on.

Yeah, sorry, I was lazy about digging up the history. I think the
problem actually started in ae0ba8e20a (Teach @{upstream} syntax to
strbuf_branchanme(), 2010-01-19), when the features were ported over
from get_sha1() to interpret_branch_name().

Since I need to re-roll anyway, I'll tweak this to be more accurate.

> > @@ -405,7 +405,7 @@ int refname_match(const char *abbrev_name, const char *full_name)
> >  static char *substitute_branch_name(const char **string, int *len)
> >  {
> >  	struct strbuf buf = STRBUF_INIT;
> > -	int ret = interpret_branch_name(*string, *len, &buf);
> > +	int ret = interpret_branch_name(*string, *len, &buf, 0);
> >  
> >  	if (ret == *len) {
> >  		size_t size;
> 
> This is the one used by dwim_ref/log, so we'd need to allow it to
> resolve to anything, e.g. "@" -> "HEAD", and pretend that the user
> typed that expansion.  OK.

Yeah. Left them all as "0" here, and then split the updates into their
own commits. So there's no commit that says "and we are leaving this
spot, because it is correct as-is". The other notable one is the
strbuf_branchname() call in merge_name().

I can mention those in the commit message here (I think I did in the
cover letter, but it would be nice to stick it in the history, since
that will be what comes up if you blame those lines).

-Peff

  reply	other threads:[~2017-02-28 22:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27  4:52 [BUG] branch renamed to 'HEAD' Luc Van Oostenryck
2017-02-27  6:13 ` Karthik Nayak
2017-02-27  6:47   ` Luc Van Oostenryck
2017-02-27  7:49   ` Jeff King
2017-02-27  8:01     ` Jeff King
2017-02-27  9:02       ` Jeff King
2017-02-27  9:47         ` Luc Van Oostenryck
2017-02-27 22:28         ` Junio C Hamano
2017-02-27 23:05           ` Jacob Keller
2017-02-28  0:33             ` Junio C Hamano
2017-02-28  0:53               ` Jeff King
2017-02-28  7:58                 ` Jacob Keller
2017-02-28 12:06                 ` Jeff King
2017-02-28 12:07                   ` [PATCH 1/8] interpret_branch_name: move docstring to header file Jeff King
2017-02-28 12:07                   ` [PATCH 2/8] strbuf_branchname: drop return value Jeff King
2017-02-28 12:07                   ` [PATCH 3/8] strbuf_branchname: add docstring Jeff King
2017-02-28 12:14                   ` [PATCH 4/8] interpret_branch_name: allow callers to restrict expansions Jeff King
2017-02-28 12:23                     ` Jeff King
2017-02-28 12:33                       ` Jeff King
2017-02-28 20:27                     ` Junio C Hamano
2017-02-28 21:37                       ` Jeff King [this message]
2017-02-28 12:15                   ` [PATCH 5/8] t3204: test git-branch @-expansion corner cases Jeff King
2017-02-28 12:15                   ` [PATCH 6/8] branch: restrict @-expansions when deleting Jeff King
2017-02-28 12:16                   ` [PATCH 7/8] strbuf_check_ref_format(): expand only local branches Jeff King
2017-02-28 12:17                   ` [PATCH 8/8] checkout: restrict @-expansions when finding branch Jeff King
2017-02-28 22:48                   ` [BUG] branch renamed to 'HEAD' Jacob Keller
2017-03-01 17:35                     ` Junio C Hamano
2017-02-28  0:49             ` Jeff King
2017-02-28  0:42           ` Jeff King

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20170228213726.3gvwomlpn2ukdcfl@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.keller@gmail.com \
    --cc=karthik.188@gmail.com \
    --cc=luc.vanoostenryck@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).