Re: Re: [RFC v2] submodule: Respect requested branch on all clones

[Heiko Voigt <hvoigt@hvoigt.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

here my current thoughts in a kind of summary email.

On Tue, Jan 07, 2014 at 11:45:03AM -0800, W. Trevor King wrote:
> On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
> > 2014/1/7 Junio C Hamano <gitster@pobox.com>:
> > > It is not immediately obvious to me why anybody who specifies the
> > > submodule.*.branch variable to say "I want _that_ branch" not to
> > > want to be on that branch but in a detached state, so from that
> > > perspective, submodule.*.attach feels superfluous.
> > 
> > Junio, for what it concerns me I fully support this patch as, IMO, it
> > makes cleaner the role of the property "submodule.<name>.branch".
> 
> No, submodule.<name>.branch is the name of the remote-tracking branch
> for 'update --remote'.  In this patch, I'm using it as a hint for the
> preferred local branch name [1], which I now think was a bad idea.
> After [2], I think that we should just define the preferred local
> branch name explicitly (submodule.<name>.local-branch?).

I am not so sure about that. Having an extra value adds more
configuration burden to the user and it also does not help to understand
how this feature is supposed to be used.

Even though I was confused in the first place by the remote/local branch
switch for this option, after thinking a little bit more about it I
think it makes perfect sense to use the branch option as a hint for the
local branch.

Let me explain by an example. Suppose we have the following setup:

1. Fast-forward situation

    superproject      submodule

 master PA--------------->A master
                          |
                          B origin/master

Lets say superproject has submodule.submodule.branch=master and
submodule.submodule.update=merge.

Doing the initial update which clones results in the submodules master
branch being set to the sha1 registered in the superproject.

Now an update to the newest master in submodule is straightforward:

$ git submodule update --remote

2. Direct work situation

The developer start with the same setup as in situation 1 but now
directly starts to work in the submodule and creates commit C.

    superproject      submodule

 master PA--------------->A
                          |\
            origin/master B C master

$ git submodule update --remote
$ git commit -a -m "update submodule"

gets him this:

    superproject      submodule

        PA--------------->A
         |                |\
         |  origin/master B C
         |                |/
 master PB--------------->D master

Where now both the submodule and the superproject can be directly
pushed. If origin/master in the submodule is tracked by master this is
actually one command

$ git push --recurse-submodules=on-demand

So with your (Trevors) patch and reusing submodule.<name>.branch using
this kind of direct work in submodules is made easy. And wasn't that
what people always requested? ;-) Well, at least if you do not use
feature branches this makes it easy. But I think that is a good start
make the simple things easy first. Then we can later discuss the more
complicated ones. It seems to me that is also the case David wants for
his emacs/CEDET workflow: Make it easy for the superproject developers
to directly push out trivial fixes to the submodule.

And it also seems to me that is want Francesco wants.

One thing is missing though (and I think thats where Francesco came
from): What if the developer already has a detached HEAD in the
submodule?

How does he attach to a branch? For this we need something similar to
Francescos attach/detach or Trevors submodule checkout with Junio's checkout
HEAD~0 from here[1].

I am still undecided how we should call it. Because of my

Idea for feature branch support
- -------------------------------

For the branch attaching feature I would also like something that can actually
modify .git/config and for me more importantly .gitmodules.

So e.g. if I want to work on a longer lived feature branch in a submodule which
I need in a feature branch in the superproject I would do something like this:

$ git submodule checkout --gitmodules --merge -b hv/my-cool-feature

Which should create a local feature branch hv/my-cool-feature in the submodule,
checkout that branch and modify .gitmodules (because of --gitmodules) to have
submodule.<name>.update=merge, submodule.<name>.branch=hv/my-cool-feature and
stage that to the index.

This is a temporary setting so everyone who is working together can update
their branches easily. Once finished (with the prove that the big feature in
the superproject works) everyone can go and polish the submodule branches,
get their changes accepted there first, and then the update/branch setting
local for this branch will be dropped. In this workflow these settings never
enter a stable branch but are still very useful to transport this information
while developing.

Just an idea of a future extension we should keep in mind when designing the
command to attach to a branch. But maybe the command to configure this should
be completely independent from checkout. I.e.:

git submodule checkout - syncs to a possible update/branch
git submodule attach   - creates a submodule branch and configures
			 update/branch in .git/config or .gitmodules
git submodule detach?  - reverse attach

or maybe --attach and --detach in this scenario could be options to checkout?

Still unsure...

Cheers Heiko

[1] http://article.gmane.org/gmane.comp.version-control.git/240097
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iEYEARECAAYFAlLMggIACgkQjLR3Aoip+rpoMACgpn4XzDD4CvD+HCi8coIlwueP
gQUAn1v1BSJ+k8IJT7S/hwtojT+sUmgP
=GGTX
-----END PGP SIGNATURE-----