Re: [RFC v2] submodule: Respect requested branch on all clones

On Mon, Jan 06, 2014 at 04:47:39PM +0100, Heiko Voigt wrote:

That's right. Anyone who wants to do local development in a submodule should probably not be using checkout updates, hence my proposal above to base local-branch creation on submodule.<name>.update.

This sounds too complicated to me ;).

This sounds like my quoted realization above. We both even preface the idea with "thinking" ;). However, I think merge, rebase, !command, and all other non-checkout update schemes are already signals that the developer is interested in local developent (and therefore wants a branch), without the need to add an aditional 'pull' (and then how to distinguish between rebase/merge?).

With my patch this happens with the initial clone-update (as of v2, only when submodule.<name>.branch is set. In a hypothetical v3, only when submodule.<name>.update is not checkout). I'm not sure we want to do this if the user switches to non-checkout updates after the initial cloning update though. They may actually have work in that detached HEAD that we'd be clobbering.

I think that updating using the gitlinked sha1 (a local update) and updating using the upstream origin/$branch (a --remote update) should always be two distinct events. Combining them in a single operation just complicates the situation.

That's what we already have with submodule.<name>.update as 'merge'. The merged object is either the gitlinked sha1 (a local update) or a re-fetched upstream branch tip (a --remote update).

The way I keep this straight is:

1. Submodules are links to Git commits (that's how they're stored in
   the index).
2. There are two places to look if you want to update the linked
   commit:
   a. The superproject's tree (a local updates).
   b. The remote subproject's current submodule.<name>.branch tip (a
      --remote update).
3. There are a number of ways to integrate external updates with your
   local submodule development.
   a. checkout: blow away local development
   b. merge: merge the update into the local branch
   c. rebase: rebase the local branch onto the update
   d. !command: do something fancier

We currently have easy config and command-line switches to select between 2.a and 2.b, which for me makes extending 1 to support floating branches unnecessary. Note that we're always updating to a referenced sha1, and there are only two places we can look to find that sha1.

We also have easy config and command-line switches to select between 3.a, 3.b, 3.c, and 3.d.

One thing that's a bit fuzzy is the definition of "local development". We're currently treating it as "any commits leading up to HEAD that are not in the update source", which works well until upstream starts rebasing (or rolling back to an earlier release, etc.). It's hard for Git to handle that sort of thing automatically, for all the usual "recovering from upstream rebase" reasons [1]. I'm fine if we leave it up to users to resolve this sort of situation by hand. Folks with local work should know what was local, and folks without local work can use a checkout update.

We're also not doing a great job of setting people up for local development, but that's tricky if they may already have local work. My "start them on a branch" patch is not saving anyone a lot of work, but it's a step in that direction. Doing anything after the initial cloning update is going to be much harder, because there's not much that would be unabmiguously helpful. After all, the current submodule implementation supports my workflows pretty well.

Cheers, Trevor

[1]: See "RECOVERING FROM UPSTREAM REBASE" in git-rebase(1).