"Glen Choo via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> During the v1 discussion, I realize that my idea of the new submodule UX has
> already diverged from what was initially communicated to the list. I plan to
> check in a technical document describing the plans for new submodule UX,
> which should hopefully make these discussions smoother (e.g. the commit
> message in patch 7 can make reference to the doc).
Good.
> = 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.
> = Future work
>
> * Patch 5, which refactors resolve_gitlink_ref(), notes that a better
> interface would be to return the refname instead of using an "out"
> parameter, but we use an "out" parameter so that any new callers trying
> to use the old function signature will get stopped by the compiler. The
> refactor can be finished at a later time.
OK.
> * Patch 5 uses the name "target" when we are talking about what a symref
> points to, instead of "referent" like the other functions. "target" is
> the better choice, since "referent" could also apply to non-symbolic
> refs, but that cleanup is quite big.
I do not see a huge difference between the two. "target" can be
used in contexts that are not about symbolic refs, and "referent"
can be used in contexts that are not about symbolic refs, too. As
long as they are unified in one way or another, it would be fine.
