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@xxxxxxxxx/t/#u
https://lore.kernel.org/git/20130607124146.GF28668@xxxxxxxxxxxxxxx/t/#u
Cheers,
Philippe.
