From: Paul Jakma <hidden> Date: 2016-06-15 22:42:21
Hi,
Next dumb question:
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?
I'm guessing the answer is:
Yes:
1. where git-reset has already been done, manually update the
refs back to the previous HEAD
2. then use git-revert, and continue to use git-revert only.
My question then would be, presuming some innocent repository
maintainer has already done 1, what's the easiest way to accomplish
1?
(they shouldn't have done it obviously, but assume they're git
newbies, made an honest mistake and now need to recover, preferably
without having to involve those who pull).
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Be cautious in your daily affairs.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
Paul Jakma wrote:
Hi,
Next dumb question:
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?
I'm guessing the answer is:
Yes:
1. where git-reset has already been done, manually update the
refs back to the previous HEAD
2. then use git-revert, and continue to use git-revert only.
My question then would be, presuming some innocent repository maintainer
has already done 1, what's the easiest way to accomplish 1?
(they shouldn't have done it obviously, but assume they're git newbies,
made an honest mistake and now need to recover, preferably without
having to involve those who pull).
I *think* this should work. Get a backup before trying. Note that I'm
assuming "git reset" hasn't been run several times, or you'll have to
replace ORIGIN with whatever HEAD pointed to before the first reset.
In mothership-repo:
git checkout master
git branch next-master ORIGIN
git rebase next-master; # fix conflicts and commit
git branch -d master
git checkout -b master next-master
git -d next-master
git revert (the bad commits)
Some shortcuts can be taken if we're not to use git commands the entire
way, but this is easier to explain to those newbie-ish people you mentioned.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
On Thu, 16 Mar 2006 14:34:42 +0000 (GMT)
Paul Jakma [off-list ref] wrote:
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?
It's still not a recommended operation on a repository that is pulled
by others. If you realize you made a mistake by resetting the head,
you can undo the operation afterward with:
$ git reset ORIG_HEAD
Sean
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
Andreas Ericsson wrote:
git branch next-master ORIGIN
s/ORIGIN/ORIG_HEAD/
otherwise the advice still applies.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Paul Jakma <hidden> Date: 2016-06-15 22:42:21
On Thu, 16 Mar 2006, sean wrote:
$ git reset ORIG_HEAD
Ah, of course :).
Thanks.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
There's no such thing as pure pleasure; some anxiety always goes with it.
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:21
Paul Jakma [off-list ref] writes:
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.
From: Jon Loeliger <hidden> Date: 2016-06-15 22:42:21
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:21
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:
quoted
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).
quoted
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".
quoted
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
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:21
Dear diary, on Fri, Mar 17, 2006 at 03:10:23AM CET, I got a letter
where Junio C Hamano [off-list ref] said that...
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.
Just for the sake of completeness, this is a GIT-only doctrine; Cogito
is more confiding and has less strict requirements.
First, when fetching, it does not care at all whether the new head is a
fast-forward of the original one or not.
Second, when the people who are tracking you had A as their current
master head _and_ also the origin remote head (or whichever their
respective branch names are), their current master head will be updated
to B when cg-updating, as Cogito pretends it to be a fast-forward even
though it is not.
So, in the simple tracking cases, Cogito will do the right thing, if you
use cg-update.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.