Re: [PATCH v3] branch: add flags and config to inherit tracking

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 18, 2021, 22:11 UTC
Message-ID: <87sfwyx8ux.fsf@gmgdl.gmail.com>
In-Reply-To: <xmqqk0iauhwu.fsf@gitster.g>

On Mon, Oct 18 2021, Junio C Hamano wrote:

Show 13 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Sat, Oct 16 2021, Josh Steadmon wrote:
>>
>>> It can be helpful when creating a new branch to use the existing
>>> tracking configuration from the branch point. However, there is
>>> currently not a method to automatically do so.
>>
>> There's no method to get *only* that config, but this use-case is why
>> the "-c" option (copy branch) was added.
>
> Hmph, I doubt the claim about the original motivation behind "-c",
> but it sure sounds like an interesting point of view.

While I didn't implement --copy, a co-worker of mine at the time did (in 52d59cc6452 (branch: add a --copy (-c) option to go with --move (-m), 2017-06-18)).

He wanted to try to submit a patch series to git.git, and came to me asking for ideas for things to work on. I suggested that he come up with something that had personally irked him, was lacking from his POV etc.

After coming up blank there I suggested something to the effect of "well, if you want to just hack on git.git, but can't come up with anything, I've got a pretty long personal TODO list in that area, so...".

The feature is the result of that discussion & my mentoring it. So yes, it's useful for other things as a side-effect of scratching that particular itch. But in terms of why we ended up with it that's the exact use-case it's intended for.

Show 5 quoted lines

> The commit at the tip, as well as configurations are copied, which is
> most of the way there, but I suspect that the --track=inherit is
> mostly to be used in the context of "git checkout -b" and the mention
> of "branch" is merely for simplicity of the description of this topic,
> no?  And you cannot say "git checkout --clone-branch original" (yet).

Yes, this has integration with "git checkout", but "git branch --copy" doesn't.

The original iteration of "git branch --copy" that didn't make it into git.git would switch you to the branch (so behave like checkout). So there is a "git checkout --clone-branch" equivalent out there in the ML archive, it was just invoked via "git branch".

I think at the time I advocated for having those "checkout" semantics, but in retrospect I'm happy we didn't go with that, per the table I later posted at [1]. That UX would be very confusing.

But we should have some way of doing "copy config and switch", and per [1] we don't have that yet.

So now with this patch we'll have "copy remote config [and switch]"? I'm not saying that's a bad thing as as incremental step, but it might be worth thinking of the UX here more holistically. And Josh: I think some extension/update of that ASCII table I posted in[1] would be very useful to explain this change (and compare it to "branch -c").

1. https://lore.kernel.org/git/877dkdwgfe.fsf@evledraar.gmail.com/