On Tue, Jun 13, 2017 at 7:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Sahil Dua <sahildua2305@xxxxxxxxx> 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. Okay, "it makes sense to do the same" was not the best way to say it. Basically what it meant was that considering there are conflicting opinions about how --copy should work with respect to checking out branch automatically, it makes sense to do it the same way as --move just to come to a conclusion. If we get user feedback that a lot of users find it annoying, we can make it work the other way around (without checkout branch automatically). I will fix the commit message to explain this in v2. Is that okay?