Preferred local submodule branches (was: Introduce git submodule attached update)

From: W. Trevor King <wking@tremily.us>
Date: Jan 7, 2014, 22:36 UTC
Message-ID: <20140107223625.GB29954@odin.tremily.us>
In-Reply-To: <20140107041004.GA11060@odin.tremily.us>

On Tue, Jan 07, 2014 at 10:51:34PM +0100, Francesco Pretto wrote:

Show 10 quoted lines

> 2014/1/7 W. Trevor King <wking@tremily.us>:
> >
> > I'd be happy to hear ideas about superproject-branch-specific local
> > overrides to a hypothetical submodule.<name>.local-branch, in the
> > event that a developer doesn't like a default set in .gitmodules.  If
> > I could think of a way to do that, we could avoid this heuristic
> > approach, and make the local submodule.<name>.local-branch
> > vs. remote-tracking submodule.<name>.branch distinction more obvious.
> 
> Uh, I think you got it wrong in the other thread:

I'm grafting this discussion back on to the thread where I proposed submodule.<name>.local-branch.

> I didn't proposed such feature.

Right.  I proposed this feature after reading your proposed workflow.

> I just wanted the attached submodule use case to be supported and of
> course "--branch means attached" is even easier to get this.

As I understood it, the '--branch means attached' stuff was tied up with automatic --remote updates.

There are three branches that submodule folks usually care about:

1. The linked $sha1 in the superproject (set explicitly for every
   superproject commit, and thus for every superproject branch).
2. The remote-tracking submodule.<name>.branch that lives in the
   upstream submodule.<name>.url repository.
3. The submodule's locally checked out branch, which we currently let
   the developer setup by hand, which is used integrated with one of
   the other two branches during non-checkout updates.

Git is currently a bit weak on conveniently handling type-3 branches. “Just use what the developer has setup” works well for many basic workflows, but falls short for:

* Cloning-updates, where we currently always setup a detached HEAD.
* Workflows where the preferred type-3 branch depends on the
  superproject branch.

The former is easy to fix [1] if you accept submodule.<name>.branch as a guess, but this conflates the type-2 and type-3 branches.

For the latter, you'd want something like:

On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:

Show 8 quoted lines

> * Auto checkout of the preferred branch
>   * Can do this at clone-update time with my patch.
>   * For later submodule branch switches, maybe we want:
> 
>       git submodule checkout [-b <branch>] [<paths>…]
> 
>     Then if a user blows off their detached HEAD, at least they'll
>     feel a bit sheepish afterwards.

which would likely need some of Jens' new core checkout handling [2].

Cheers, Trevor

[1]: Using something along the lines of my
     http://article.gmane.org/gmane.comp.version-control.git/239967
[2]: http://article.gmane.org/gmane.comp.version-control.git/240117

-- 
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