Re: What's cooking in git.git (Jul 2017, #04; Thu, 13)

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 17, 2017, 17:55 UTC
Message-ID: <xmqqtw2bgd8q.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <87iniu2bty.fsf@gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 7 quoted lines

> Let's see what *nix does:
>
>     $ rm -rf /tmp/{master,backup}; mkdir /tmp/master && cd /tmp/master && mv /tmp/{master,backup} ; file /tmp/{master,backup}
>
> Similarly to that, when you're on "master" "git branch --move backup"
> could have left you on an orphan branch, but it doesn't, it's the
> equivalent of "mv && cd" in *nix terms.

And with the same analogy,

	mkdir /tmp/master
	cd /tmp/master
	cp -R /tmp/master /tmp/backup
	pwd

would show you that you are still in /tmp/master. Which is quite different from what happens with "mv". So what's your point?

In any case, you already realize that it is a crazy and convoluted example nobody does in real life to go in to one directory *and* rename it while you are inside it, don't you?

The reason why I do not think it is wise to move to the backup branch when you did

	git checkout master
	git branch --copy master backup

is not because of that crazy analogy, though. It is primarily that I think one of the major reasons people want to do a "copy" to a backup is to keep the pre-modification state of a thing that they may be able to later come back to when it turns out to be needed. For that workflow, with the above "branch --copy", your user is planning to make a change that is not usually kept track of by Git to the "master" branch (perhaps branch.*.description is changed, perhaps the remote-tracking branch it is set to integrate with is changed, etc.), but the user is unsuare, and preparing a backup that can be used with "gir branch -M backup master" to come back to.

You can do all that even if your "branch --copy" initially takes you to the "backup" branch you just created, but then the user has to immediately come back to "master" to start doing the major surgery on "master", for which the "copy" was a preparation to recover.

> So since our --move is really --move-and-checkout I think it would be
> confusing to introduce a --copy sister option that has the semantics of
> --copy-no-checkout instead of a corresponding --copy-and-checkout.

Our --move is *NOT* --move-and-checkout.

	git chekckout master
	git branch naster
	git branch -m naster aster

will *not* move "naster" to "aster" and check it out. During the whole exercise, you will stay on "master".

When you rename the current branch so that the name of the current branch will no longer exist in the system, you _could_ detach the HEAD, or you _could_ move the current branch to the new name. There is no sensible alternative other than these two, but either way, you need to have a special case for renaming the current branch. It's just the latter is more useful in practice and that is the only reason why it moves _you_ along with the current branch if you happen to be on that branch being renamed.

I do not see much reason why such a special case has to apply to "copy". The source of the copy is not going away, and in the "backup" scenario, moving away from the thing that is backed up, in preparation for further work that may have to be reverted, is actively counter-productive.

There however _is_ an opposite use case. You may want to start working on a _new_ branch that is more similarly set up to what your current branch is, _and_ you want the new branch to start at your current branch. But I think that should be done by adding an enhanced mode of "checkout -b". IOW, I think

	git checkout master
	git checkout -b --with-configuration naster [master]

is a very sensible thing to desire; if "master" is set to integrate with refs/remotes/origin/master, the new "naster" branch may want to integrate with refs/remotes/origin/naster (instead of the local "master", which is what the traditional "checkout -b" would do), for example. Or you could do the same thing with

	git branch --copy master naster
	git checkout naster

if your "branch --copy" does not switch out of the current branch.