Re: RFC/Discussion - Submodule UX Improvements

[Philippe Blain <levraiphilippeblain@gmail.com>]

Le 2021-04-20 à 19:03, Emily Shaffer a écrit :

>>> When it's time to update their local repo, the user can do so as with a
>>> single-repo project. First they can 'git checkout main && git pull' (or 'git
>>> pull -r'); Git will first checkout the branches associated with main in each
>>> submodule, then fetch and merge/rebase in each submodule appropriately.
>>
>> What if some submodule does not use the same branch name for their primary integration branch?
>> Sometimes as a superproject using another project as a submodule, you do not
>> control that...
> 
> Yeah, you're right that that's an important consideration - "how can I
> teach my superproject to default to a different branch than the name of
> the superproject's current branch?" I wonder whether the branch config
> in .gitmodules (or an equivalent in superproject's .git/config) would
> make sense to try and use here?

I think it depends on the workflow. Re-reading the above, I would definitely *not* want
'git pull --recurse-submodules' in the superproject to go into each submodule
and do 'git pull' there ! Because maybe some submodule introduced breaking changes
in its API or something and I do not want to deal with that now; I just want to update my tree
with the latest changes *to the superproject* (and maybe to the submodules *if* they
were updated by the superproject, but not if they were updated in the submodule upstream project).
For me, 'git pull --recurse-submodules'
has mostly the right behaviour today, except what does not work (doing something useful
when both sides record changes to the submodule pointer).


> 
>> Also, usually tracking info is only set
>> automatically when using the form 'git checkout -b new-branch upstream/master' or
>> the like. Do you also propose that 'git checkout -b new-branch', by itself, should
>> automatically set tracking info ?
> 
> Yes - that is an approach that we want to explore, to solve the general
> push/fetch remote+branch problem.

Yeah, it would be nice if the triangular workflow capabilities of Git would be expanded
(if I understand correctly that's what you are hinting at here). My personal TODO list
for that has the following items (just dumping that here in case it's useful to someone):

# improve UI/UX around 'branch.pushRemote' and 'remote.pushDefault'
- git branch --verbose could show difference with @{push} in addition to / instead of @{upstream}
- git status "
- git prompt "
- add config branch.<name>.pushBranch (or pushRef)
- add 'git branch --set-push-to remote/name' to set branch.name.pushRemote and branch.name.pushRef
- add 'git push -p <remote> <branch>' to set 'branch.name.pushRemote' and 'branch.name.pushRef' (and warn if push.default is not 'current') OR:
- allow 'branch.pushRemote' and 'remote.pushDefault' to work if push.default=simple
- reword push.default section in git-config  (very unclear)

https://lore.kernel.org/git/87d0q72du2.fsf@javad.com/t/#u
https://lore.kernel.org/git/20130607124146.GF28668@sociomantic.com/t/#u


Cheers,

Philippe.