git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 3/4] branch: correctly reject refs/heads/{-dash,HEAD}
Date: Thu, 16 Nov 2017 22:32:42 +0530
Message-ID: <d2bd10c1-be6a-25e2-47cf-613f34ed9513@gmail.com> (raw)
In-Reply-To: <xmqqlgj6uv8k.fsf@gitster.mtv.corp.google.com>

On Thursday 16 November 2017 08:27 PM, Junio C Hamano wrote:
> Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:
> 
>> I guess this series is not yet ready for 'next'. When I tried to apply
>> this patch it doesn't seem to be applying cleanly. I get some
>> conflicts in 'sha1_name.c' possibly as a consequence of the changes to
>> the file that aren't accounted by the patch.
> 
> Oh, it is totally expected that this patch (and others) may not
> apply on 'next' without conflict resolution, as this topic, as all
> the other topics, are designed to apply cleanly to either 'master'
> or 'maint' or one of the older 'maint-*' series, if it is a bugfix
> topic.  A patch series that only applies cleanly to 'next' would be
> useless---it would mean all the topics that are already in 'next'
> that interacts with it must graduate first before it can go in.

Thanks for the explanation. Seems I still have to become accustomed to 
the workflow.


> Make it a habit to build on 'master' or older and then merge to
> higher integration branches to make sure it fits with others.
>

Though I don't clearly understand how to do that, I'll let experience 
teach me the same (if possible). :-)


> What you could do is to inspect origin/pu branch after you fetch,
> and look at the commit that merges this topic to learn how the
> conflicts are resolved (the contrib/rerere-train.sh script may help
> this process).
> 

Sure thing.


>>> +	if (*name == '-' ||
>>> +	    !strcmp(sb->buf, "refs/heads/HEAD"))
>>
>> I guess this check should be made more consistent. Possibly either of,
> 
> Among these two, this one
> 
>> 	if (starts_with(sb->buf, "refs/heads/-") ||
>> 	    !strcmp(sb->buf, "refs/heads/HEAD"))
> 
> has more chance to be correct.  Also, if we were to check the result
> of expansion in sb->buf[], I would think that we should keep a
> separate variable that points at &sb->buf[11] and compare the
> remainder against fixed strings, as we already know sb->buf[] starts
> with "refs/heads/" due to our splicing in the fixed string.
> 
> Because the point of using strbuf_branchname() is to allow us expand
> funny notations like @{-1} to refs/heads/foo, and the result of
> expansion is what eventually matters, checking name[] is wrong, I
> would think, even though I haven't thought things through.
> 
> In any case, I would say thinking this part through should be left
> as a theme for a follow-on patch, and not within the scope of this
> one.  After all, checking *name against '-' was part of the original
> code, so it is safer to keep the thing we are not touching bug-to-bug
> compatible and fixing things one step at a time (the one fix we made
> with this patch is to make sure we store refs/heads/-dash in sb when
> we reject name=="-dash").
> 

Good point. This is better for a follow-up patch as there's a 
possibility that we might be introducing new bugs which weren't present 
previously as a consequence of changing that conditional (bug-to-bug 
compatibility, good term that (possibly) summarizes my long-winded 
explanation ;-)

      reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-13  5:11 [PATCH 0/3] a small branch API clean-up Junio C Hamano
2017-10-13  5:11 ` [PATCH 1/3] branch: streamline "attr_only" handling in validate_new_branchname() Junio C Hamano
2017-10-13  7:05   ` Eric Sunshine
2017-10-13  5:11 ` [PATCH 2/3] branch: split validate_new_branchname() into two Junio C Hamano
2017-10-21  4:58   ` Kaartic Sivaraam
2017-10-21  9:01     ` Junio C Hamano
2017-10-13  5:11 ` [PATCH 3/3] branch: forbid refs/heads/HEAD Junio C Hamano
2017-10-13 13:15   ` Jeff King
2017-10-14  2:11     ` Junio C Hamano
2017-10-14  2:20       ` Junio C Hamano
2017-10-16 21:38         ` Jeff King
2017-10-21  4:50         ` Kaartic Sivaraam
2017-10-21  8:57           ` Junio C Hamano
2017-10-22  5:00             ` Kaartic Sivaraam
2017-10-21  3:07 ` [PATCH 0/3] a small branch API clean-up Kaartic Sivaraam
2017-10-21  8:52   ` Junio C Hamano
2017-10-22  4:36     ` Kaartic Sivaraam
2017-11-14 11:42 ` [PATCH v2 1/2] branch: forbid refs/heads/HEAD Kaartic Sivaraam
2017-11-14 11:42   ` [PATCH v2 2/2] builtin/branch: remove redundant check for HEAD Kaartic Sivaraam
2017-11-14 12:00   ` [PATCH v2 1/2] branch: forbid refs/heads/HEAD Kaartic Sivaraam
2017-11-14 15:08     ` Junio C Hamano
2017-11-15 16:59       ` Kaartic Sivaraam
2017-11-15 22:14         ` [PATCH 3/4] branch: correctly reject refs/heads/{-dash,HEAD} Junio C Hamano
2017-11-16 13:11           ` Kaartic Sivaraam
2017-11-16 14:57             ` Junio C Hamano
2017-11-16 17:02               ` Kaartic Sivaraam [this message]

Reply instructions:

You may reply publically 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=d2bd10c1-be6a-25e2-47cf-613f34ed9513@gmail.com \
    --to=kaartic.sivaraam@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox