RE: RFC/Discussion - Submodule UX Improvements

["Randall S. Becker" <rsbecker@nexbridge.com>]

On April 20, 2021 2:50 PM, Emily Shaffer wrote:
> On Mon, Apr 19, 2021 at 08:56:43AM -0400, Aaron Schrab wrote:
> >
> > At 16:36 -0700 16 Apr 2021, Emily Shaffer <emilyshaffer@google.com>
> wrote:
> > > - git switch / git checkout
> >
> > (snip)
> >
> > > 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
> > >     we could just check out the branch by that name and print a
warning to
> the
> > >     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
> > >     the tree is identical to the tree we would have used as the start
point
> > >     (that is, the user switched branches in the submodule, then said
"oh crap"
> > >     and went back and switched branches in the superproject).
> > >  b. Tracking info is set appropriately on each new branch to the
upstream of
> > >     the branch referenced by the parent of the new superproject
commit, OR
> to
> > >     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.