Re: [PATCH 3/3] branch: add a --copy (-c) option to go with --move (-m)

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sahil Dua <sahildua2305@gmail.com> writes:
>>
>>> Add the ability to --copy a branch and its reflog and configuration,
>>> this uses the same underlying machinery as the --move (-m) option
>>> except the reflog and configuration is copied instead of being moved.
>>>
>>> This is useful for e.g. copying a topic branch to a new version,
>>> e.g. work to work-2 after submitting the work topic to the list, while
>>> preserving all the tracking info and other configuration that goes
>>> with the branch, and unlike --move keeping the other already-submitted
>>> branch around for reference.
>>>
>>> Like --move, when the source branch is the currently checked out
>>> branch the HEAD is moved to the destination branch. In the case of
>>> --move we don't really have a choice (other than remaining on a
>>> detached HEAD), but it makes sense to do the same for --copy.
>>
>> I strongly disagree with this "it makes sense to do the same".  It
>> would equally (if not more) make sense to keep the HEAD pointing at
>> the same.
>>
>> Personally, I may use this feature if it didn't move HEAD, but I
>> wouldn't if HEAD gets moved.  But that may be just me.
>
> Ah, that came out to be stronger than I intended.
>
> While I do prefer "the HEAD is not moved by this command---if you
> want to move to the newly created branch after copying, check it out
> yourself" a lot better than what the patch does, I do not think I'd
> care so strongly that I'd reject this patch series unless the
> behaviour is changed.
>
> But I do react strongly to an unsubstantiated claim "it makes sense
> to do the same".  I can buy "We anticipate that in 50% of the case
> users would find this branch switching annoying and in the other 50%
> of the case, users would find it useful; since we need to pick one,
> we just randomly decide to do the same as --move", though.