non-fastforward push: action required... maybe

[Jim Meyering]

My error.

I had tagged, created the signed tarball and tested before
this last-minute (when I was releasing) change:

    From 53398ec2976b5e2813c26146a11e8966e6a8120d Mon Sep 17 00:00:00 2001
    From: Aharon Robbins <address@hidden>
    Date: Thu, 16 Sep 2010 13:12:11 +0200
    Subject: [PATCH] dfa: fix compilation when not using MBS

and then I didn't realize I'd missed a commit until after I'd uploaded
the tarballs to ftp.gnu.org.  Hence, the above patch did not make it into
the 2.7 release.  But that is not a problem, since it's mainly to keep
in sync with gawk's copy of that file.  I suspect that no one builds
grep without defining MBS (it wouldn't have compiled).

However, that did pose a small problem.  I couldn't immediately follow
the normal release procedure, retaining the NEWS-modifying commit
(the one that's tagged with the release number) because that commit
would conflict with the one above: a so-called non-fastforward commit.
We have a pretty strict policy of not permitting non-fastforward commits
on public branches like this one, but breaking the rule this time seemed
justified, so I did it, thus effectively deleting the above commit in
favor of the tagged commit and the following administrivia one.

Then I could proceed with the release process.
Once done, I reapplied the above patch and pushed it.

----------------------------------------
The following concerns only people who have
a grep.git repository that is up to date enough
to include the above commit.  I.e., if

    git show 53398ec2976b5e2813c26146a11e8966e6a8120d

prints nothing, then you can safely ignore the following.
--------------------------------------------------------

This may cause trouble for you if you track the grep.git
repository and a you pulled in the above commit.
Here's how to work around it.

How do you recover?
Easiest is to simply clone from scratch,
but that's no good if you have local changes.
If you're not too uncomfortable with git, do this:

   * first, commit any changes you may have

   * if you're on the "master" branch, save its state on a branch, just in case:

        git checkout -b $(date +%j)-snapshot

   * get back on master:

        git checkout master

   * "unlink" from master all changes prior to the above commit:

        git reset --hard 53398ec2976b5e2813c26146a11e8966e6a8120d^

   * now pull, fetch or whatever you do to get the latest:

        git pull