RE: [RFC] Branches with --recurse-submodules

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Nov 10, 2021, 20:25 UTC
Message-ID: <000a01d7d671$1c7d4820$5577d860$@nexbridge.com>
In-Reply-To: <kl6lee7nvm6t.fsf@chooglen-macbookpro.roam.corp.google.com>

On November 10, 2021 2:35 PM, Glen Choo wrote:

Show 12 quoted lines

> 
> Overall, I think your workflow is not too dissimilar to the UX we are proposing
> :)
> 
> <rsbecker@nexbridge.com> writes:
> 
> > 4. If working on the submodule, use a branch, not a commit - typically off
> main.
> 
> With the proposed UX, step (4) would happen automatically when using
> "branch --recurse-submodules". Users would get a safer and more
> convenient default.

I think this might be more reliably done using a switch in .gitconfig to enable the capabilities. Perhaps something like:

submodule.fetch-branches=true

Show 10 quoted lines

> > What I could see as a possible improvement is to add the branch ref to the
> submodule ref file - not replacing the commit but adding to it. I do worry that
> there are unintended (unforeseen) side-effects that will result from this,
> however, including potential merge conflicts. Two people working on the
> same commit but different branches may mess the ref file, so not really a
> good idea.
> 
> It's an interesting idea, but as you noted, it is quite thorny. I would also like to
> see more information being captured by the superproject tree (instead of
> just .gitmodules), but I'm also not sure how we might do that.

I'm suggesting this instead of a command-line option because this seems more like a policy-based process that you would either always want or never want. I would not like to depend on a developer making the call each time a clone occurred. I'm sad to admit that I don't really know where to start on this enhancement, though, even if approved. -Randall