RE: RFC/Discussion - Submodule UX Improvements

From: Randall S. Becker <rsbecker@nexbridge.com>
Date: Apr 20, 2021, 19:29 UTC
Message-ID: <019c01d7361b$82344700$869cd500$@nexbridge.com>
In-Reply-To: <YH8iTDNZpsoCu+lx@google.com>

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

Show 10 quoted lines

> 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

Show 5 quoted lines

> 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

Show 11 quoted lines

> 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.