git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Tight submodule bindings

From
W. Trevor King <wking@tremily.us>
Date
Jan 14, 2014, 02:44 UTC
Message-ID
<20140114024426.GB23617@odin.tremily.us>
In-Reply-To
<xmqqk3e35y3p.fsf@gitster.dls.corp.google.com>
On Mon, Jan 13, 2014 at 02:13:46PM -0800, Junio C Hamano wrote:
Show 15 quoted lines
> "W. Trevor King" <wking@tremily.us> writes:
> 
> > Additional metadata, the initial checkout, and syncing down
> > -----------------------------------------------------------
> >
> > However, folks who do local submodule development will care about
> > which submodule commit is responsible for that tree, because
> > that's going to be the base of their local development.  They also
> > care about additional out-of-tree information, including the
> > branch that commit is on.
> 
> Well, please step back a bit.
> 
> They do not have to care about what local branch they use to build
> follow-up work based on that commit.

They do if they want to checkout the banch out again later, before pushing it somewhere public.

> In fact, they would want to be able to develop more than one
> histories on top, which means more than one branches they can name
> themselves.

Agreed, bug for each superproject branch they will still have a single submodule branch that should be checked out by default when they checkout that superproject branch.

> The only thing they care about is where the result of their
> development _goes_, that is the URL and the branch of the remote
> they are pushing back to.

Maybe they're just doing local development? I think the remote branch(es) you pull from and push to are important, but not the only thing you might care about.

Show 15 quoted lines
> I have a feeling that this is not specific for submodules---if you
> did this:
> 
> 	git init here
>         cd here
>         git fetch $there master
>         git reset --hard FETCH_HEAD
> 
> and are given the resulting working tree to start hacking on, you
> would not know where the history came from, or where your result
> wants to go.  
> 
> So "the branch that commit is on" is a wrong thing to focus on.
> "The branch the history built on top of the commit wants to go" may
> be closer and these two are different.

That makes sense. I don't think the former (as distinct from the latter) is of any interest to anybody. I don't care what the branch name was when the past history was developed. I don't even really care about the new branch name. I do care that checking out a superproject branch gives me the same branch (with pull/push configs, etc.) that I had the last time I was on that superproject branch.

Show 11 quoted lines
> >  For already-initialized submodules, there are existing places
> > in the submodule config to store this configuration:
> >
> > 1. HEAD for the checked-out branch,
> > 2. branch.<name>.remote → remote.<name>.url for the upstream
> >    subproject URL,
> > 4. branch.<name>.rebase (or pull.rebase) to prefer rebase over merge
> >    for integration,
> > 5. …
> 
> What happened to 3 ;-)?
I can't count? :p
> In any case, "local-branch" is wrong from two aspects:
> 
>  1. (obvious) It does not follow our naming convention not to use
>     dashed-names for configuration variables.

I'll use localBranch in my mockup ;). Although skimming through config.txt shows a number of alllowercase settings as well as camelCase.

>  2. You do not care about the names you use locally.  The only thing
>     you care about is where people meet at the central repository,
>     i.e. where your result is pushed to.
I also care about local-checkout consistency, as described above.
Show 11 quoted lines
> > Syncing up
> > ----------
> >
> > In the previous section I explained how data should flow from
> > .gitmodules into out-of-tree configs.
> 
> s/should/you think should/, I think, but another way may be not to
> copy and read from there, which may be a lot simpler.  Then upon
> switching branches of top-level superproject (which would update
> .gitmodules to the version on the new branch), you may get different
> settings automatically.

That only works for superproject-level commands that know about the .gitmodules file. If you cd into the submodule and work there directly, your actions will be using the submodule's out-of-tree config. I think most of the time folks will want those out-of-tree configs to match the settings in the superproject's .gitmodules, hence the submodule.<name>.sync defaulting to true.

Show 9 quoted lines
> > ...  Since you *will* want to share the upstream URL, I proposed
> > using an explicit submodule.<name>.active setting to store the “do
> > I care” information [2], instead of overloading
> > submodule.<name>.url (I'd auto-sync the .gitmodule's
> > submodule.<name>.url with the subproject's remote.origin.url
> > unless the user opted out of .gitmodules syncing).
> 
> It may not be a good idea to blindly update to whatever happens to
> be in .gitmodules, especially once submodule.*.url is initialized.

Why not? We're blindly updating it to the value that was previously pulled out of the submodule's out-of-tree config. If the user doesn't like what's happening to .gitmodules upstream and doesn't want to keep a patched version locally, they can always turn off submodule.<name>.sync.

Show 10 quoted lines
> Imagine that your embedded appliance project used to use a submodule
> from git://k.org/linux-2.6 as its kernel component and now the
> upstream of it is instead called just git://k.org/linux; the URL
> specified by submodule.kernel.url in .gitmodules for the entry
> submodule.kernel.path=kernel would have changed from the former to
> the latter sometime in the superproject's history.  Switching back
> to an old version in the superproject to fix an old bug in the
> maintenance track of the superproject would still want to push
> associated fixes to the kernel to k.org/linux, not linux-2.6, the
> latter of which may now be defunct [*1*].

The checkout would work (because the old gitlinked commit is already in the local repository), but the push would not. I don't think it would be difficult to recover from that manually (and just specify the full URL when pushing). You could also:

1. Commit your fix.
2. Checkout a more modern superproject branch (which will load the
   current URL into the submodule's config).
3. Push the fix.
4. Continue to work on the modern branch.
That doesn't sound much more difficult than the ideal:
1. Commit your fix.
2. Push the fix.
3. Checkout a more modern superproject branch (which will load the
   current URL into the submodule's config).
4. Continue to work on the modern branch.

If you expect to be back making more superproject/subproject joint bugfixes in future, I think it makes sense to start a maintenance branch of the superproject that updates the .gitmodules URL to point at the modern location.

Cheers, Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Previous: Junio C HamanoNext: Heiko Voigt
Message 26 of 40 in “git-submodule.sh: Support 'checkout' as a valid update command”
  1. 1/2 git-submodule.sh: Support 'checkout' as a valid update commandFrancesco Pretto, Jan 5, 2014
  2. 2/2 Introduce git submodule attached updateFrancesco Pretto, Jan 5, 2014
  3. Francesco PrettoJan 5, 2014
  4. Heiko VoigtJan 5, 2014
  5. Francesco PrettoJan 5, 2014
  6. Heiko VoigtJan 6, 2014
  7. Francesco PrettoJan 6, 2014
  8. David EngsterJan 6, 2014
  9. W. Trevor KingJan 7, 2014
  10. W. Trevor KingJan 7, 2014
  11. Preferred local submodule branches (was: Introduce git submodule attached update)W. Trevor King, Jan 7, 2014
  12. W. Trevor KingJan 7, 2014
  13. W. Trevor KingJan 8, 2014
  14. W. Trevor KingJan 8, 2014
  15. 0/4 Preferred local submodule branchesW. Trevor King, Jan 9, 2014
  16. 1/4 submodule: Add helpers for configurable local branchesW. Trevor King, Jan 9, 2014
  17. 2/4 submodule: Teach 'update' to preserve local branchesW. Trevor King, Jan 9, 2014
  18. 3/4 submodule: Teach 'add' about a configurable local-branchW. Trevor King, Jan 9, 2014
  19. Francesco PrettoJan 15, 2014
  20. W. Trevor KingJan 15, 2014
  21. 4/4 submodule: Add a new 'checkout' commandW. Trevor King, Jan 9, 2014
  22. Tight submodule bindings (was: Preferred local submodule branches)W. Trevor King, Jan 12, 2014
  23. Jens LehmannJan 13, 2014
  24. W. Trevor KingJan 13, 2014
  25. Junio C HamanoJan 13, 2014
  26. W. Trevor KingJan 14, 2014
  27. Heiko VoigtJan 7, 2014
  28. W. Trevor KingJan 7, 2014
  29. Junio C HamanoJan 7, 2014
  30. Francesco PrettoJan 7, 2014
  31. Junio C HamanoJan 7, 2014
  32. Francesco PrettoJan 7, 2014
  33. Francesco PrettoJan 5, 2014
  34. Heiko VoigtJan 6, 2014
  35. W. Trevor KingJan 6, 2014
  36. Heiko VoigtJan 5, 2014
  37. W. Trevor KingJan 5, 2014
  38. Junio C HamanoJan 6, 2014
  39. Junio C HamanoJan 6, 2014
  40. Francesco PrettoJan 6, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.