I'm in sort of shallow waters, hoping that Junio or Linus will come along and pull me off the shores in case I mis-step and say something stupid that would have made an amusing pictograph had it been done right by a cartoonist. Jon Loeliger wrote: > 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? > "Ours" is an algorithm you can invent yourself and pass as the defautl merge strategy (useful if you know you'll always keep upstream as-is or some such). > >>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? > Yes, and/or no. "Ours"' is still whatever you want it to be. Perhaps we should add some new strategies, like "favour-current" and "favour-new". > >> 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? > Because the commits pullers already have are now inside the respository history, as seen by average pullers (again). The merge between "master" (or some such) and "new-devel" (or some such) happen to coincide, which means they share a mutual merge-base, which means they're both part of the same chain of developemnt. If you intend to disimiss most of the changes between (fork-point) and (point-of-new-weird-rebase) this might not be the best solution, but... Sorry, but to me this is friaday night and currently I can't logically differ between a bluewhale and a kangaroo [*1] /exon [1] Sadly, this has been empirically proven. [*2] [2] At some other time. I'm no *that* drunk right now. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Mar 18 08:22:19 2006
This archive was generated by hypermail 2.1.8 : 2006-03-18 08:22:32 EST