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[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]. Will have a look. > > That should be all (and IIRC Francesco agreed) needed for that use-case. > > That was my understanding [3] ;). 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) [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 ;). 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 actually want. Cheers Heiko > [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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html