On Fri, Feb 21, 2014 at 8:51 PM, Walter Bright <walter@digitalmars.com> wrote:

But I had just pulled the latest master and did a refresh on github to ensure there had been no new changes before I pushed. I'm still a bit baffled why that didn't work.

When you did git reset --soft HEAD^ it picked the testCols commit, because you had merged master into that branch rather than the other way around.

So, what's the correct procedure to undo the last commit to master?

The way I usually do it is to look at the history (git log, gitk, or the internals list) to get the hash of the last correct merge commit, then `git reset --hard` to that.

But this can seriously screw things up if done wrong, so if you're not 110% sure it's best to just let somebody else fix it.

On 2/21/2014 1:40 AM, Daniel Murphy wrote:

You had an old master, with your testCols commit on top. Then you merged upstream master into it. Then you pushed that merge commit to upstream, accidentally.

When you 'fixed' it, you made the testCols commit the new master. This discarded all the changes from the upstream master. (from the last day or so)

Luckily this doesn't seem to happen very often. To make this less likely, I recommend you do not pull from upstream master manually, and you instead have a sh/batch file that runs: `git pull upstream master --ff-only` which will fail loudly if you have made changed in your master branch (rather than silently creating a merge commit).

As for CRLFs, I recommend turning git's autocrlf off, so git no longer messes with your line endings.

https://github.com/D-Programming-Language/dmd/pull/3307

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals