On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote: > > 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 Junio, Can you explain a bit more why the "ours" strategy comes into play here? I _think_ I understand, but I'd like to hear a bit more explanation, please. How is this different from just merging in A directly? > You want to keep the contents of the cleaned-up HEAD, so that is > why you are taking the tree from B. And the "ours" strategy effectively says, "Favor the B side of things when pulling in the A parts", right? > 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. This is mystical to me. How is the "A" (ie, side branch) now in a "recovered" state? Thanks, jdl - : 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