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

> On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
> > I would like to step back a bit and get back to the original problem
> > at hand: Francescos original use case of an attached head for direct
> > commits on a stable branch in a submodule. How about we finish
> > discussing the exact solution of that first. AFAIK that is already
> > solved with the following:
> > 
> >  * Trevor's first patch[2] to create a branch on initial clone of a submodule
> 
> v1 broke a bunch of tests.  Are you ok with v2 [1]?  v2 still needs a
> clearer commit message, a test, and a possible transition to
> triggering on non-checkout submodule.<name>.update instead of
> non-empty submodule.<name>.branch [2].

> > Lets not implement more than currently is needed. We can revisit the
> > ideas once some other real use-case manifests.
> 
> I have most of a real use case already.  I have a repository with
> submodules in one branch (master) and a subtree version in another
> (assembled) [4].  The *tree* is the same in each case, so I have to
> 'git rm -rf .'  to clear the submodules out of master before I can
> checkout assembled.
> 
>   $ git checkout assembled
>   error: The following untracked working tree files would be overwritten by checkout:
>           modular/README.md
>           modular/shell/README.md
>           …
>   $ git rm -rf .
>   $ git checkout assembled
> 
> That leaves some extra stuff removed:
> 
>   $ git status
>   On branch assembled
>   Changes to be committed:
>     (use "git reset HEAD <file>..." to unstage)
> 
>           deleted:    .gitignore
>           deleted:    .mailmap
>           deleted:    CONTRIBUTING.md
>           deleted:    LICENSE.md
>           deleted:    instructor.md
> 
> so I need to check that out by hand:
> 
>   $ git reset --hard HEAD
> 
> Now I can work in the assembled branch.  Going back to master is a bit
> less tedious:
> 
>   $ git checkout master
>   $ git submodule update --recursive
> 
> Luckily for me, I don't have a third superproject branch where the
> submodules are on a different, so the submodule's HEADs are preserved.
> As I understand it, the new recursive checkout functionality [5] would
> checkout my submodules with detached HEADs.  The fact that they are
> only accidentally preserved now is not comforting ;).

> > Also we (Jens and I) would first like to proceed with the recursive
> > checkout / fetch (for which the plan is clear) as the next
> > complicated step.
> > 
> > Once that is done and people gain some experience with it we can
> > still extend further.
> 
> This is quite reasonable.  Given the need for backwards compatibility,
> I just wanted to make sure my ideal UI was clear before we went
> forward.  There's no need to break fingers twice ;), but if tight
> binding with localBranch is too big a chunk to bite off now, I'm happy
> to kick that can down the road.

> [1]: http://article.gmane.org/gmane.comp.version-control.git/239967
> [2]: http://article.gmane.org/gmane.comp.version-control.git/239973
> [3]: http://article.gmane.org/gmane.comp.version-control.git/240139
> [4]: (gitweb) http://git.tremily.us/?p=swc-boot-camp.git
> [5]: http://article.gmane.org/gmane.comp.version-control.git/239695