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