On 1 Nov 2013, at 17:09, John Dennis <jdennis@redhat.com> wrote:
On 11/01/2013 12:26 PM, Arran Cudbard-Bell wrote:
On 1 Nov 2013, at 15:30, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Did someone rebase master? I just failed a ff-merge on my local copy (no changes) and some commits appear to have changed IDs e.g.
-commit 287390887d81e3c4a1379dd11c2b176d45cb5a91 +commit a3bab0eafc07e3f32c311c3f412f39560e8b6183 Author: Arran Cudbard-Bell <a.cudbardb@freeradius.org> Date: Thu Oct 17 17:32:07 2013 +0100
Typo
...and about 10 more.
Alan was unhappy about the Mavericks commits I made. They were removed from both branches and redone by him.
If you rewind before the point of the divergence and pull it should be fine.
git reset --hard HEAD~5 git pull
Rewriting history on a shared git repository is considered a no-no for exactly this reason (it breaks the trees of cloned repos).
No. One or more branches of the repository diverge, they do not break.
A better approach would have been to make a new commit that corrected the prior commit with a clear commit message indicating what happened (including referencing the commit id being "repaired")
There are multiple ways you can fix diverged repos, if you don't have commits of your own you can rewind a few commits back and pull, if you do have commits you can use git rebase -i, dig out commits back to the point of divergence and git pull --rebase. No, rewriting history is not a good thing to do, but neither is it some kind of apocalyptic repository destroying event. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team