Re: git-reset and clones

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Paul Jakma <paul@xxxxxxxx> 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.



-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]