archive mirror
 help / color / mirror / Atom feed
From: Philippe Blain <>
To: Emily Shaffer <>
Subject: Re: RFC/Discussion - Submodule UX Improvements
Date: Tue, 20 Apr 2021 22:27:19 -0400	[thread overview]
Message-ID: <> (raw)
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.<name>.pushBranch (or pushRef)
- add 'git branch --set-push-to remote/name' to set and
- add 'git push -p <remote> <branch>' to set '' and '' (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)



  parent reply	other threads:[~2021-04-21  2:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 23:36 RFC/Discussion - Submodule UX Improvements Emily Shaffer
2021-04-18  5:22 ` Christian Couder
2021-04-20 23:10   ` Emily Shaffer
2021-04-19  3:20 ` Philippe Blain
2021-04-20 23:03   ` Emily Shaffer
2021-04-20 23:30     ` Junio C Hamano
2021-04-21  2:27     ` Philippe Blain [this message]
2021-04-19 12:56 ` Randall S. Becker
2021-04-19 12:56 ` Aaron Schrab
2021-04-20 18:49   ` Emily Shaffer
2021-04-20 19:29     ` Randall S. Becker
2021-04-19 19:14 ` Jacob Keller
2021-04-19 19:28   ` Randall S. Becker
2021-04-20 16:18     ` Jacob Keller
2021-04-20 18:47       ` Emily Shaffer
2021-04-20 19:38         ` Randall S. Becker
2021-04-21  6:57         ` Jacob Keller
2021-04-22 15:32 ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).