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.