Re: [PATCH/RFC v4 3/3] branch: add copy branch feature implementation
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 6, 2017, 00:10 UTC
- Message-ID
- <xmqqlgp69ds9.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <CALiud+=qoSSSg_p2MXZEaVTGMhFW_FtirDJ2-FnmNh+U0yf0Gw@mail.gmail.com>
Sahil Dua <sahildua2305@gmail.com> writes:
Show 18 quoted lines
> 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).