RFC: git subrepos

[Matt Mackall]

On Tue, 2010-11-09 at 01:06 -0500, Eric Eisner wrote:
> - Updating to a specific git commit loses the git branch.
>     Even if there is a branch there, should hg check it out?
>     What if there is more than one branch at a commit?
> - If git does not have a branch checked out, a further commit is not
> officially referenced and thus never pushed and may be subject to
> garbage collection.
> - 'git push' pushes branches, not commits

Ok, here's a simple scenario:

State 0: Alice clones git project X, checking out branch Y at changeset A1
State 1: Alice commits changeset A2 to branch Y
State 2: Alice pushes
         Bob pulls, commits B1-B5 to branch Y
State 3: Alice commits changeset A3 to branch Y

Git presumably allows the above. Git presumably also allows us to clone
Bob's repo, and force the clone into a state where it's at A2 and the
next commit will be on branch Y, thus emulating Alice's 'natural'
transition above from state 2 to state 3.

So the job of subrepos is to store enough information about state 2 so
that we can proceed to state 3. It sounds like that means storing the
branch name in the state and forcibly setting it on checkout.

-- 
Mathematics is the supreme nostalgia of our time.