Ah! I had skipped this reply from Ramsay earlier. On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On 31/07/17 23:30, Junio C Hamano wrote: > [snip] >> >> * sd/branch-copy (2017-06-18) 3 commits >> (merged to 'next' on 2017-07-18 at 5e3b9357ea) >> + branch: add a --copy (-c) option to go with --move (-m) >> + branch: add test for -m renaming multiple config sections >> + config: create a function to format section headers >> >> "git branch" learned "-c/-C" to create and switch to a new branch >> by copying an existing one. >> >> Will cook in 'next'. >> >> I personally do not think "branch --copy master backup" while on >> "master" that switches to "backup" is a good UI, and I *will* say >> "I told you so" when users complain after we merge this down to >> 'master'. > > I wouldn't normally comment on an issue like this because I am > not very good at specifying, designing and evaluating UIs (so > who in their right mind would listen to me). ;-) > > FWIW, I suspect that I would not like using this interface either > and would, therefore, not use it. Does that mean you'd use it when "branch --copy feature-branch new-feature-branch" in the case when you would want to start working on a new branch (to modify or experiment with your current feature branch) on top of a branch keeping intact all the configuration and logs? I think it's really a matter of how this feature is seen from the end-user point of view. If we consider example "branch --copy master backup" - obviously, switching to backup isn't the ideal situation. However, if we consider the example above, switching makes sense. None of them is going to be correct in 100% cases. :) > However, I guess the worst that > would happen, is that it would gain another 'wort' (--option) to > turn off the "switches to backup" branch. :-D > > I didn't want you to think that the lack of comments on this was > because everybody agreed that it was a good idea. > > ATB, > Ramsay Jones > >
