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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
: 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