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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to