3 ms·

Why not just revert the offending commit? It would be a valid blip in history as mistake made and corrected.

OJFord 10y ago
> It occurred to me while I was writing this that it would probably have worked to make one commit on master to remove the back-end files again, and then rebase the entire topic branch onto that commit. But I didn't think of it at the time. And it's not as good as what I did do, which left the history as clean as was possible at that point.
- barrkel 10y ago
  He could have made the reversion commit on a local branch (branched from master), then rebased interactively to reorder / squash commits. It presupposes that the commits are clean and well-separated though.
- soft_dev_person 10y ago
  I read that, but it doesn't read like he is aware of the option to revert a commit directly. More that he would remove them manually and commit that. Little difference, but if "as clean as possible" was the goal, I think that would be the cleanest. [edit] added the little words that my keyboard seems to filter out.
  - OJFord 10y ago
    Maybe you're right; I agree that's probably what I would have done. Apart from anything else it allows a clean-slate "this is how it _should_ have been handled in the first place", rather than a separate git-fu move that was necessary or even relevant only because of the original indiscretion.
rwmj 10y ago
Another thing is not to fear the non-fast-forward commit. Sure you'll need to tell the other developers (apparently "a hundred" in this case, but more often just a handful of people in the same room) that they have to reset back a few commits before pulling, but that's not the end of the world.
- bluehex 10y ago
  Not only that but the failure case when a developer pulls before receiving the memo isn't that bad. Git tells you that the branch was force updated and working out what to do from there is usually pretty easy.
latortuga 10y ago
Admittedly I did not read the whole post, but I agree that this sounds like the right answer. He made a mistake on master by merging a partial topic branch. The answer is to revert the mistake (git revert abc123) and then either rebase+merge or just merge the whole topic branch. I also don't agree with his conclusion that his way left the history in a better state - reverting the commit actually represents the mistake that was made.
OskarS 10y ago
Yeah, that was my instinct as well. The problem was that the first user did that kooky way of bringing the 18 files over with `git checkout`. That's a terrible idea, both because it lead to the catastrophe here, but also because you lose all history of those changes, they appear brand new in that commit (which makes `git bisect` and `git blame` much less useful). No, just `git revert` that terrible commit, then do a regular sensible merge/rebase. Solves all problems in, like, two commands.

> It occurred to me while I was writing this that it would probably have worked to make one commit on master to remove the back-end files again, and then rebase the entire topic branch onto that commit. But I didn't think of it at the time. And it's not as good as what I did do, which left the history as clean as was possible at that point.

barrkel 10y ago
He could have made the reversion commit on a local branch (branched from master), then rebased interactively to reorder / squash commits. It presupposes that the commits are clean and well-separated though.
soft_dev_person 10y ago
I read that, but it doesn't read like he is aware of the option to revert a commit directly. More that he would remove them manually and commit that. Little difference, but if "as clean as possible" was the goal, I think that would be the cleanest. [edit] added the little words that my keyboard seems to filter out.
- OJFord 10y ago
  Maybe you're right; I agree that's probably what I would have done. Apart from anything else it allows a clean-slate "this is how it _should_ have been handled in the first place", rather than a separate git-fu move that was necessary or even relevant only because of the original indiscretion.

rwmj 10y ago

Another thing is not to fear the non-fast-forward commit. Sure you'll need to tell the other developers (apparently "a hundred" in this case, but more often just a handful of people in the same room) that they have to reset back a few commits before pulling, but that's not the end of the world.

bluehex 10y ago
Not only that but the failure case when a developer pulls before receiving the memo isn't that bad. Git tells you that the branch was force updated and working out what to do from there is usually pretty easy.

latortuga 10y ago

Admittedly I did not read the whole post, but I agree that this sounds like the right answer. He made a mistake on master by merging a partial topic branch. The answer is to revert the mistake (git revert abc123) and then either rebase+merge or just merge the whole topic branch. I also don't agree with his conclusion that his way left the history in a better state - reverting the commit actually represents the mistake that was made.

OskarS 10y ago

Yeah, that was my instinct as well. The problem was that the first user did that kooky way of bringing the 18 files over with `git checkout`. That's a terrible idea, both because it lead to the catastrophe here, but also because you lose all history of those changes, they appear brand new in that commit (which makes `git bisect` and `git blame` much less useful). No, just `git revert` that terrible commit, then do a regular sensible merge/rebase. Solves all problems in, like, two commands.