On April 20, 2021 2:50 PM, Emily Shaffer wrote:

On Mon, Apr 19, 2021 at 08:56:43AM -0400, Aaron Schrab wrote:

quoted

At 16:36 -0700 16 Apr 2021, Emily Shaffer [off-list ref]

wrote:

quoted

quoted

- git switch / git checkout

(snip)

quoted

4. A new branch with the same name is created on each submodule.
 a. If there is a naming conflict, we could prompt the user to resolve

it, or

quoted

quoted

    we could just check out the branch by that name and print a

warning to

the

quoted

quoted

    user with advice on how to solve it (cd submodule && git switch -c
    different-branch-name HEAD@{1}). Maybe we could skip the

warning/advice if

quoted

quoted

    the tree is identical to the tree we would have used as the start

point

quoted

quoted

    (that is, the user switched branches in the submodule, then said

"oh crap"

quoted

quoted

    and went back and switched branches in the superproject).
 b. Tracking info is set appropriately on each new branch to the

upstream of

quoted

quoted

    the branch referenced by the parent of the new superproject

commit, OR

to

quoted

quoted

    the default branch's upstream.
5. The new branch is checked out on each of the submodules.

In many cases the branch name for the superproject isn't going to be
appropriate for submodules.

This seems likely to create a LOT of junk branches. Do you also have a
proposal for cleaning those up?

Yeah, I think we have a point internally for "clean up alllll the

submodule

branches that are unreferenced/already merged". You're right that in a
workflow where I have a superproject with eight submodules, because I need
them to build, but only do active development on one submodule out of the
eight, I'll have a ton of junk refs in the other seven submodules. Yuck :)

In fact, this yuck is a reason why many organizations have gone to
monolithic repositories instead of multiple smaller ones - because of the
touch points. However, the argument for using multiple smaller repos mirrors
this particular use case, so while "yuck", it might have value when
mirroring what happens in the issue tracking systems that have massive touch
points. We were there and moved to monolithic per product release group, but
when we had the other approach, this particular feature actually would have
helped a whole lot. I wonder whether this mess might have more value than we
think.

Regards,
Randall

-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
MVS not admitting to anything
-- In my real life, I talk too much.