git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Sahil Dua <sahildua2305@gmail.com>,
	git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Brandon Williams <bmwill@google.com>
Subject: Re: [PATCH 4/3] branch: fix "copy" to never touch HEAD
Date: Tue, 26 Sep 2017 23:39:40 +0200	[thread overview]
Message-ID: <874lrpw34z.fsf@evledraar.booking.com> (raw)
In-Reply-To: <xmqqvakbjpo5.fsf_-_@gitster.mtv.corp.google.com>


On Fri, Sep 22 2017, Junio C. Hamano jotted:

> When creating a new branch B by copying the branch A that happens to
> be the current branch, it also updates HEAD to point at the new
> branch.  It probably was made this way because "git branch -c A B"
> piggybacked its implementation on "git branch -m A B",
>
> This does not match the usual expectation.  If I were sitting on a
> blue chair, and somebody comes and repaints it to red, I would
> accept ending up sitting on a chair that is now red (I am also OK to
> stand, instead, as there no longer is my favourite blue chair).  But
> if somebody creates a new red chair, modelling it after the blue
> chair I am sitting on, I do not expect to be booted off of the blue
> chair and ending up on sitting on the new red one.
>
> Let's fix this before it hits 'next'.  Those who want to create a
> new branch and switch to it can do "git checkout B" after doing a
> "git branch -c B", and if that operation is so useful and deserves a
> short-hand way to do so, perhaps extend "git checkout -b B" to copy
> configurations while creating the new branch B.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>  * Let's send an updated one as a follow-up to the discussion thread
>    that it is a follow-up to.  The patch in this message is the same
>    as the one I previously sent; the proposed log message has been
>    updated somewhat.
>
>  builtin/branch.c  |  9 +++------
>  t/t3200-branch.sh | 10 +++++-----
>  2 files changed, 8 insertions(+), 11 deletions(-)

This mostly looks good to me.

I've already spent several screenfuls here on-list arguing for not
applying the equivalent of this patch, which I won't repeat here.

But just a brief comment: I think this doing this is good, and it's
something I agree with given that the consensus is going this way. I
thought "do what -m does" was less confusing, but since everyone (you,
Brad, even Sahil) seems to disagree I'm happy to be shown to be wrong &
to have this go in so thoroughly reviewed & thought about.

I do think however that we also need to update the docs, the relevant
origin/master...gitster/sd/branch-copy diff is currently:

    +The `-c` and `-C` options have the exact same semantics as `-m` and
    +`-M`, except instead of the branch being renamed it along with its
    +config and reflog will be copied to a new name.

Suggestions welcome, but I think that should probably be changed to
something like the following as part of this patch:

    The `-c` and `-C` options have the exact same semantics as `-m` and
    `-M`, except instead of the branch being renamed it along with its
    config and reflog will be copied to a new name. Furthermore, unlike
    its `-m` and `-M` cousins the `-c` and `-C` options will never move
    the HEAD, whereas the move option will do so if the source branch is
    the currently checked-out branch.

> diff --git a/builtin/branch.c b/builtin/branch.c
> index 89f64f4123..e2e3692838 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -506,12 +506,9 @@ static void copy_or_rename_branch(const char *oldname, const char *newname, int
>  				oldref.buf + 11);
>  	}
>
> -	if (replace_each_worktree_head_symref(oldref.buf, newref.buf, logmsg.buf)) {
> -		if (copy)
> -			die(_("Branch copied to %s, but HEAD is not updated!"), newname);
> -		else
> -			die(_("Branch renamed to %s, but HEAD is not updated!"), newname);
> -	}
> +	if (!copy &&
> +	    replace_each_worktree_head_symref(oldref.buf, newref.buf, logmsg.buf))
> +		die(_("Branch renamed to %s, but HEAD is not updated!"), newname);
>
>  	strbuf_release(&logmsg);
>
> diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
> index 5d03ad16f6..be9b3784c6 100755
> --- a/t/t3200-branch.sh
> +++ b/t/t3200-branch.sh
> @@ -422,7 +422,7 @@ test_expect_success 'git branch --copy is a synonym for -c' '
>  	test_cmp expect actual
>  '
>
> -test_expect_success 'git branch -c ee ef should copy and checkout branch ef' '
> +test_expect_success 'git branch -c ee ef should copy to create branch ef' '
>  	git checkout -b ee &&
>  	git reflog exists refs/heads/ee &&
>  	git config branch.ee.dummy Hello &&
> @@ -431,7 +431,7 @@ test_expect_success 'git branch -c ee ef should copy and checkout branch ef' '
>  	git reflog exists refs/heads/ef &&
>  	test $(git config branch.ee.dummy) = Hello &&
>  	test $(git config branch.ef.dummy) = Hello &&
> -	test $(git rev-parse --abbrev-ref HEAD) = ef
> +	test $(git rev-parse --abbrev-ref HEAD) = ee
>  '
>
>  test_expect_success 'git branch -c f/f g/g should work' '
> @@ -494,12 +494,12 @@ test_expect_success 'git branch -C c1 c2 should succeed when c1 is checked out'
>  	git checkout -b c1 &&
>  	git branch c2 &&
>  	git branch -C c1 c2 &&
> -	test $(git rev-parse --abbrev-ref HEAD) = c2
> +	test $(git rev-parse --abbrev-ref HEAD) = c1
>  '
>
> -test_expect_success 'git branch -C c1 c2 should add entries to .git/logs/HEAD' '
> +test_expect_success 'git branch -C c1 c2 should never touch HEAD' '
>  	msg="Branch: copied refs/heads/c1 to refs/heads/c2" &&
> -	grep "$msg$" .git/logs/HEAD
> +	! grep "$msg$" .git/logs/HEAD
>  '
>
>  test_expect_success 'git branch -C master should work when master is checked out' '

  parent reply	other threads:[~2017-09-26 21:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-05 22:35 What's cooking in git.git (Jul 2017, #01; Wed, 5) Junio C Hamano
2017-07-05 23:06 ` Stefan Beller
2017-07-07  2:13   ` Junio C Hamano
2017-07-10 17:27     ` Stefan Beller
2017-07-05 23:14 ` [PATCH v2 0/3] branch: add a --copy to go with --move Ævar Arnfjörð Bjarmason
2017-07-06  0:37   ` Junio C Hamano
2017-09-22  4:57     ` [PATCH 4/3] branch: fix "copy" to never touch HEAD Junio C Hamano
2017-09-22 16:33       ` Brandon Williams
2017-09-26 21:39       ` Ævar Arnfjörð Bjarmason [this message]
2017-09-27  2:02         ` Junio C Hamano
2017-09-29 18:30           ` Ævar Arnfjörð Bjarmason
2017-07-05 23:14 ` [PATCH v2 1/3] config: create a function to format section headers Ævar Arnfjörð Bjarmason
2017-07-05 23:14 ` [PATCH v2 2/3] branch: add test for -m renaming multiple config sections Ævar Arnfjörð Bjarmason
2017-07-05 23:14 ` [PATCH v2 3/3] branch: add a --copy (-c) option to go with --move (-m) Ævar Arnfjörð Bjarmason

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=874lrpw34z.fsf@evledraar.booking.com \
    --to=avarab@gmail.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=sahildua2305@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).