Re: [PATCH v2 0/7] clone, submodule update: check out submodule branches

[Glen Choo <chooglen@google.com>]

Junio C Hamano <gitster@pobox.com> writes:

> "Glen Choo via GitGitGadget" <gitgitgadget@gmail.com> writes:
>> = Description
>>
>> This series teaches "git clone --recurse-submodules" and "git submodule
>> update" to understand "submodule.propagateBranches" (see Further Reading for
>> context), i.e. if the superproject has a branch checked out and a submodule
>> is cloned, the submodule will have the same branch checked out.
>>
>> To do this, "git submodule update" checks if ...
>> = Series history
>>
>> Changes in v2:
>>
>>  * The superproject's "submodule.propagateBranches" value is always used,
>>    even if false.
>>  * Branches are now created at clone time (by adding a new flag to "git
>>    submodule clone"), instead of at update time.
>>  * Rebase onto newer master. This got adjusted slightly to incorporate
>>    ab/submodule-helper-leakfix.
>>  * Add more tests to demonstrate edge case behavior.
>>  * Assorted commit message and doc improvements.
>
> As the previous round was more than a month old and is clearly not a
> bugfix but is adding a new feature, I do not mind updating to the
> newer base after a new feature release was made.  There isn't much
> to be gained, other than that we can easily sanity check by running
> "git diff @{1} @{0}" on the branch to compare the iterations, by
> keeping the same base.  We are not going to merge this topic down to
> maintenance tracks after it graduates to 'master' anyway.
>
> But I got curious and tried to adjust these patches back on the
> previous base 07ee72db (Sync with 'maint', 2022-08-26).  It turns
> out that the conflicts needed to be resolved were fairly trivial.
>
> Merging the topic that was recreated on top of the same old base
> into today's 'master' of course needed the same conflict resolution
> but that is something we've been doing every time we rebuild 'seen'
> (read: at least twice a day, but often more).  Applying these
> patches directly on today's 'master' of course produced the
> identical tree as the tree of this trial merge.

Thanks for your patience. For future reference, do you have a preference
either way? I suppose choosing a later base might make it easier for
reviewers who don't have the bandwidth to remember what "master" used to
look like, but it's just churn to you, since you're already rebuilding
"seen".