Re: git-reset and clones

From: Junio C Hamano <junkio@cox.net>
Date: Mar 17, 2006, 02:10 UTC
Message-ID: <7v4q1x95yo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org>

Paul Jakma <paul@clubi.ie> writes:

Show 14 quoted lines

> If a git repository has a reset HEAD~X done, then any later pulls in
> clone repositories get /really/ upset, with:
>
> $ git pull
> * refs/heads/origin: does not fast forward to branch 'master' of
> /home/paul/foo-git/;
>
> Type of thing. This seems to be a similar issue to:
>
> 	http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
>
> The question is has this improved at all since last year? Is there
> anything the origin repository maintainer (the one who did reset) can
> do to recover from this?

You used to have something like this:

                 o---o---o---A
                /            ^ your HEAD used to point at here
    ---o---o---o

and you forgot other people already have the commit chain up to commit A. But you rewound and did cleanups:

                 o---o---o---A
                /
    ---o---o---o---o---o---B
                           ^ your HEAD now points at here

People who track your HEAD have A and your updated head B does not fast forward. Oops.

The recovery consists of two steps. The first step is more important. To find what commits you lost that others already may have. You may be lucky and remember A's commit object name, but when I did that I had to ask around on the list X-<.

The second step is a single command:

	$ git merge -s ours 'Graft the lost side branch back in' \
		HEAD A

where A is the object name of that commit. On your current branch, this creates a merge commit between A and B (your current HEAD), taking the tree object from B.

                 o---o---o---A
                /             \
    ---o---o---o---o---o---B---M

You want to keep the contents of the cleaned-up HEAD, so that is why you are taking the tree from B. With this commit M, you are telling the outside world that it is OK if they start from a commit on the now-recovered side branch.

If the tree of A and B exactly match, further merges with people starting from A branch would not have conflicts. If the difference between A and B are mostly clean-ups, automerge would lose dirtiness you cleaned-up when they update to your new HEAD (because the transition from A to M reverts the dirtiness, which is what your clean-up was about), which is what you want.