On Tue, Jan 14, 2014 at 02:22:31PM -0800, W. Trevor King wrote:
> 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 to create a branch on initial clone of a
> > submodule
> v1 broke a bunch of tests. Are you ok with v2 ? 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 .
Will have a look.
> > That should be all (and IIRC Francesco agreed) needed for that use-case.
> That was my understanding  ;).
Thanks for the pointer.
> > 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) . 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
> $ 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  would
> checkout my submodules with detached HEADs. The fact that they are
> only accidentally preserved now is not comforting ;).
As it will be opt-in first (you will have to enable it with config
options) you can keep your current workflow. Once done with the initial
implementation we can discuss and iron out use-cases like yours.
> > 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.
Yes, that would be good to clearly understand and find out what we
> : http://article.gmane.org/gmane.comp.version-control.git/239967
> : http://article.gmane.org/gmane.comp.version-control.git/239973
> : http://article.gmane.org/gmane.comp.version-control.git/240139
> : (gitweb) http://git.tremily.us/?p=swc-boot-camp.git
> : http://article.gmane.org/gmane.comp.version-control.git/239695
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html