From: Philippe Blain Date: Wed, 21 Apr 2021 02:27:19 GMT Subject: Re: RFC/Discussion - Submodule UX Improvements Message-ID: In-Reply-To: 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..pushBranch (or pushRef) - add 'git branch --set-push-to remote/name' to set branch.name.pushRemote and branch.name.pushRef - add 'git push -p ' 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.