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
signature.asc
Description: OpenPGP digital signature
