RFC: git subrepos

[Kevin Bullock]

On Nov 9, 2010, at 10:55 AM, Matt Mackall wrote:

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

What git does is to create a new ref—in state 1, Alice has branches:

origin/Y -> parent(A1)
Y -> A2

When she pushes, (IIUC) origin/Y (which is just Y on the upstream repo) points to A2. In state 3, Alice has [if she's pulled from Bob]:

Y -> A3
origin/Y -> B5

I believe git will complain about that situation if Alice tries to commit w/o first merging origin/Y or setting a new branch name. What I suggested on IRC was to detect that situation in recursive commit and abort, telling the user to set a branch name (possibly providing a convenience option a la `hg commit --git-branch BRANCHNAME` to do it in one step).

There's a related situation for push: Assume Alice didn't pull Bob's changes. Now, if she tries to push, upstream git will fail, telling her to pull and merge. This situation could be detected too, and the push aborted with an appropriate message. (I think I suggested on IRC to `git fetch` in the subrepo, but the upstream error on push would probably be enough information, and wouldn't throw off the usual git workflow.)

I don't think there's a way around making the user handle it manually in either case, though.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock

> 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.
> 
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel