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

[Junio C Hamano <gitster@pobox.com>]

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

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