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

From: W. Trevor King <wking@tremily.us>
Date: Jan 7, 2014, 23:52 UTC
Message-ID: <20140107235208.GC29954@odin.tremily.us>
In-Reply-To: <20140107223625.GB29954@odin.tremily.us>

On Tue, Jan 07, 2014 at 02:36:25PM -0800, W. Trevor King wrote:

Show 38 quoted lines

> 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:
> > * 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].
> 
> [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

For example, in Jonathan's recent version of Jens' series, the initial-setup and update functionality are moving into C. See:

* populate_submodule() [1] for the initial-clone setup (calling
  'read-tree'), and
* update_submodule() [2] for subsequent updates (calling 'checkout -q'
  with an optional '-f')

this is where any submodule.<name>.local-branch would come into play, if we decide to go down that route. It doesn't look like the C updates have the auto-clone functionality that the Bash updates have. I'm not sure if that's in the pipe or not. I'm not as familiar with the C implementation though, so maybe I'm missing the mark here.

Cheers, Trevor

[1]: http://article.gmane.org/gmane.comp.version-control.git/239698 [2]: http://article.gmane.org/gmane.comp.version-control.git/239699

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