git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Kaartic Sivaraam <kaartic.sivaraam@gmail.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 23:57:31 +0900
Message-ID: <xmqqlgj6uv8k.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <471c7b6e-d3a0-4aee-8f80-282ff0b8d972@gmail.com>

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.
Make it a habit to build on 'master' or older and then merge to
higher integration branches to make sure it fits with others.

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).

Your inability to resolve merge conflicts does not have much to do
with the readiness of a topic, as long as somebody else can resolve
them ;-)

>> +	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").


  reply index

Thread overview: 26+ 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 [this message]
2017-11-16 17:02               ` Kaartic Sivaraam

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=xmqqlgj6uv8k.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kaartic.sivaraam@gmail.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