Re: What's cooking in git.git (Jul 2017, #09; Mon, 31)

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Aug 3, 2017, 22:20 UTC
Message-ID: <50f77fb7-551c-e84b-9fef-5ed5194dc3a4@ramsayjones.plus.com>
In-Reply-To: <xmqqd18cweak.fsf@gitster.mtv.corp.google.com>

On 03/08/17 22:07, Junio C Hamano wrote:

Show 34 quoted lines

> Sahil Dua <sahildua2305@gmail.com> writes:
> 
>> Ah! I had skipped this reply from Ramsay earlier.
>>
>> On Tue, Aug 1, 2017 at 1:36 AM, Ramsay Jones
>> ...
>>>>  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 am not Ramsay, but your choice of branch names in your question,
> i.e. "branch --copy feature new-feature", is what we do not agree
> with in the first place, especially when we are *on* the "feature"
> branch.
> 
> We view "copy A B" as a way to make a back-up of A in B.  I.e. We
> want to keep working on A, but just in case we screw up badly, make
> a backup copy of A in B, so that we can recover by a "branch --move
> B A" later if needed.  So touching B is the last thing we want to do
> after "copy A B" operation---hence we do not want to switch to B.

I couldn't have said this better. ;-)

> That is not to say that you are wrong to wish to create a new
> branch, check it out and start working on it with a single command.
> We already have such a command all Git users are accustomed to,
> which is "git checkout -b new-feature-branch feature-branch".

Indeed, I wouldn't think of doing anything else. (That may be because I've been using git too long, of course).

Show 5 quoted lines

> That existing command does not copy things other than the commit
> object name from "feature-branch", and I do not think it should by
> default.  But I do not think it is wrong to extend it with a new
> option (think of it as "checkout --super-b" ;-) to copy other things
> like branch descriptions etc.

Hmm, I've never felt the lack of copying any attributes from the origin branch. So, I'm not convinced a "--super-b" is needed (but if other people feel the need, then why not).

> So from that point of view, your new feature conceptually fits a lot
> better to "git checkout", and does not belong to "git branch".  That
> is why I do not think "git branch --copy A B" while you are on A
> should check out B after creating the copy.

I agree (but lukewarm on the --super-b idea). :-D

ATB, Ramsay Jones