Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
