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 [thread overview]
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 ;-)
prev parent reply other threads:[~2017-11-16 17:05 UTC|newest]
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
2017-11-16 17:02 ` Kaartic Sivaraam [this message]
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=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
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).