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: > > 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 -- 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