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

That should be all (and IIRC Francesco agreed) needed for that use-case.

That was my understanding [3] ;).

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.

Cheers,
Trevor

[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

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