Sahil Dua [off-list ref] writes:
I want suggestions about one logical point raised by Evar.
Let's consider a case that I'm on branch maint and then I do 'git
checkout master' followed by 'git branch -m feature', it will rename
master branch to feature. Now if I do 'git checkout -' to go to the
last branch, it will take me to maint since master branch doesn't
exist in this case.
Now, for this copy operation - if I'm on branch maint and then I do
'git checkout master' followed by 'git branch -c feature', it will
copy master branch to feature. Now if I do 'git checkout -' to go to
the last branch, it will again go to maint (according to the current
implementation). What do you think it should do? Is this the desired
behavior? Or should it go to master branch since that was the branch
checked out before copying.
Also, in case this needs to be changed, can someone please point me to
how it's being handled so that I can change the behavior.
When somebody says "I want to rename my current branch to X", it is
clear that the person wants to end up being on a branch called X.
To me, "I want to copy my current branch to Y" sounds more like "I
want to create another Y that looks just like the current branch,
but I want stay on my current branch".
If you think copy makes @{-1} problematic, perhaps your copy is
doing more than it should (e.g. switching the current branch at the
same time, or something).
On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano [off-list ref] wrote:
Sahil Dua [off-list ref] writes:
quoted
I want suggestions about one logical point raised by Evar.
Let's consider a case that I'm on branch maint and then I do 'git
checkout master' followed by 'git branch -m feature', it will rename
master branch to feature. Now if I do 'git checkout -' to go to the
last branch, it will take me to maint since master branch doesn't
exist in this case.
Now, for this copy operation - if I'm on branch maint and then I do
'git checkout master' followed by 'git branch -c feature', it will
copy master branch to feature. Now if I do 'git checkout -' to go to
the last branch, it will again go to maint (according to the current
implementation). What do you think it should do? Is this the desired
behavior? Or should it go to master branch since that was the branch
checked out before copying.
Also, in case this needs to be changed, can someone please point me to
how it's being handled so that I can change the behavior.
When somebody says "I want to rename my current branch to X", it is
clear that the person wants to end up being on a branch called X.
To me, "I want to copy my current branch to Y" sounds more like "I
want to create another Y that looks just like the current branch,
but I want stay on my current branch".
This would be more useful to me if the semantics were copy & checkout
instead of just copy, since when I'd like to copy branches it's almost
always because I'm on some topic branch and want to create & work on a
new copy of that topic branch.
It would also be consistent with "git branch -m" and easier to
explain, i.e. "git branch -c just like -m except it doesn't delete the
branch name/config you moved away from".
Like with -m, you can still move around random other branches, e.g.:
# While on master
$ git branch -m some-other new-some-other
This will just move some-other to new-some-other without checkout out
new-some-other, it's only when the source name is the same as your
currently checked out branch that you checkout a new branch,
Now, of course the difference is that when you -m your current branch
it doesn't really have a choice of whether to move your checkout as
well (although I suppose it could leave you in a detached HEAD..) so
it *could* be done differently with -c, but the current behavior makes
more sense to me and matches the common case I'd use it for.
If you think copy makes @{-1} problematic, perhaps your copy is
doing more than it should (e.g. switching the current branch at the
same time, or something).
I think what Sahil is getting at is asking where the @{-N} info is
stored and why this isn't equivalent to:
$ git checkout -b one master
$ git checkout -b two master
$ git checkout master
$ git checkout one
$ git checkout two
$ git checkout - # Goes to "one", not "master"
Which is in analogous flow without this feature that switches to the
last branch, but with "git branch -c" if you were on 'one' and copied
& checked out 'two' doing 'git checkout -' would bring you back to
'master', not 'one'.
On Tue, Jun 6, 2017 at 9:39 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
On Tue, Jun 6, 2017 at 2:10 AM, Junio C Hamano [off-list ref] wrote:
quoted
Sahil Dua [off-list ref] writes:
quoted
I want suggestions about one logical point raised by Evar.
Let's consider a case that I'm on branch maint and then I do 'git
checkout master' followed by 'git branch -m feature', it will rename
master branch to feature. Now if I do 'git checkout -' to go to the
last branch, it will take me to maint since master branch doesn't
exist in this case.
Now, for this copy operation - if I'm on branch maint and then I do
'git checkout master' followed by 'git branch -c feature', it will
copy master branch to feature. Now if I do 'git checkout -' to go to
the last branch, it will again go to maint (according to the current
implementation). What do you think it should do? Is this the desired
behavior? Or should it go to master branch since that was the branch
checked out before copying.
Also, in case this needs to be changed, can someone please point me to
how it's being handled so that I can change the behavior.
When somebody says "I want to rename my current branch to X", it is
clear that the person wants to end up being on a branch called X.
To me, "I want to copy my current branch to Y" sounds more like "I
want to create another Y that looks just like the current branch,
but I want stay on my current branch".
This would be more useful to me if the semantics were copy & checkout
instead of just copy, since when I'd like to copy branches it's almost
always because I'm on some topic branch and want to create & work on a
new copy of that topic branch.
It would also be consistent with "git branch -m" and easier to
explain, i.e. "git branch -c just like -m except it doesn't delete the
branch name/config you moved away from".
Like with -m, you can still move around random other branches, e.g.:
# While on master
$ git branch -m some-other new-some-other
This will just move some-other to new-some-other without checkout out
new-some-other, it's only when the source name is the same as your
currently checked out branch that you checkout a new branch,
Now, of course the difference is that when you -m your current branch
it doesn't really have a choice of whether to move your checkout as
well (although I suppose it could leave you in a detached HEAD..) so
it *could* be done differently with -c, but the current behavior makes
more sense to me and matches the common case I'd use it for.
quoted
If you think copy makes @{-1} problematic, perhaps your copy is
doing more than it should (e.g. switching the current branch at the
same time, or something).
I think what Sahil is getting at is asking where the @{-N} info is
stored and why this isn't equivalent to:
$ git checkout -b one master
$ git checkout -b two master
$ git checkout master
$ git checkout one
$ git checkout two
$ git checkout - # Goes to "one", not "master"
Which is in analogous flow without this feature that switches to the
last branch, but with "git branch -c" if you were on 'one' and copied
& checked out 'two' doing 'git checkout -' would bring you back to
'master', not 'one'.
Yes, indeed. I am not sure how @{-N} info is stored and why it's not
doing the expected thing. Expected thing here will be to go to the
original branch from where you copied the new branch if you run 'git
checkout -'.