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

On Sun, Jan 05, 2014 at 05:12:56PM -0800, W. Trevor King wrote:

On Sun, Jan 05, 2014 at 04:33:14PM -0800, W. Trevor King wrote:

quoted

The only people who would need *automatic* rebase recovery would be
superproject devs update-cloning the subproject.  That's a small
enough cross-section that I don't think it deserves the ambiguity of
gitlink-to-reference.  In that case, all you really need is a way to
force a recovery gitlink (i.e. add a 'commit' object to the tree by
hand).

Actually, you recovering by hand is a lot easier.  Setup a
rebased-away gitlink target:

  mkdir subproject &&
  (
    cd subproject &&
    git init
    echo 'Subproject' > README &&
    git add README &&
    git commit -m 'Subproject v1' &&
    echo 'Changes' >> README &&
    git commit -am 'Subproject v2'
  ) &&
  mkdir superproject &&
  (
    cd superproject &&
    git init
    git submodule add ../subproject &&
    git commit -m 'Superproject v1'
  ) &&
  (
    cd subproject &&
    git reset --hard HEAD^ &&
    git reflog expire --expire=now --all &&
    git gc --aggressive --prune=now
  )

Then a recursive clone of the superproject dies:

  $ git clone --recursive superproject super2
  Cloning into 'super2'...
  done.
  Submodule 'subproject' (/tmp/x/subproject) registered for path 'subproject'
  Cloning into 'subproject'...
  done.
  fatal: reference is not a tree: f589144d16282d1a80d17a9032c6f1d332e38dd0
  Unable to checkout 'f589144d16282d1a80d17a9032c6f1d332e38dd0' in submodule path 'subproject'

But you still have the submodule checkout (up until the $sha1 setup):

  $ cd super2
  $ git diff
  diff --git a/subproject b/subproject
  index f589144..82d4553 160000
  --- a/subproject
  +++ b/subproject
  @@ -1 +1 @@
  -Subproject commit f589144d16282d1a80d17a9032c6f1d332e38dd0
  +Subproject commit 82d4553fe437ae014f22bbc87a082c6d19e5d9f9-dirty

And you can automatically update to match the upstream remote:

  $ git submodule update --remote --force
  Submodule path 'subproject': checked out '82d4553fe437ae014f22bbc87a082c6d19e5d9f9'
  $ git diff
  diff --git a/subproject b/subproject
  index f589144..82d4553 160000
  --- a/subproject
  +++ b/subproject
  @@ -1 +1 @@
  -Subproject commit f589144d16282d1a80d17a9032c6f1d332e38dd0
  +Subproject commit 82d4553fe437ae014f22bbc87a082c6d19e5d9f9

When explicitly updating to the superproject or subproject's
(--remote) new tip is so easy, I don't see a need for floating the
gitlinks themselves.

I agree. If we were to support this more easily we could add a
configuration option so you can omit the --remote (i.e.:
submodule.<name>.remote=true, as I also suggested in the other email).

That way the developer checking out a branch in flight does not even
need to know whether (and which) submodules sha1s are still in flight
and temporarily set this configuration in the branches .gitmodules file.

Maybe that could actually be the attach operation Francesco is
suggesting:

	git submodule attach [--pull] <submodule path> <branchname>

will attach the specified submodule to a branch. That means it changes
the .gitmodule file accordingly and stages it. With the --pull switch
one can specify whether a local branch tracking the remote branch should
be automatically created. Names and the command format are just a
suggestion here.

That way we can support the

	fork superproject needing submodule changes and send submodule
	changes upstream first.

workflow. What do you think?

Cheers Heiko