Hacker News Reader

Comment by lmm | Hacker News Reader

> The next day he wanted to go ahead and merge the front-end changes, but he found himself in “a bit of a pickle”. The merge didn't go forward cleanly, perhaps because of other changes that had been made to master in the meantime. And trying to rebase the branch onto the new master was a complete failure. Many of those 406 commits included various edits to the 18 back-end files that no longer made sense now that the finished versions of those files were in the master branch he was trying to rebase onto.

Can one not instead merge master into the feature branch?

View on HN

ding ding ding. The original dev should have made a new feature branch off master. Then they should have dropped the 18 files in, or if the 18 files had a commit history, cherry picked those commits into the new feature branch.

The next day, when he was ready for the rest of the changes, merge those into the feature branch.

These devs were trying to be clever, and got bit by it :)

KISS

I also dont see why he didnt just git revert to the parent commit, the commit before the other guy changed 18 files seemingly randomly.

Then rebased featurebranch on that, and thats it. So sure the history would contain the mistake, so what.

I'm with ya; I don't see the evil in just force pushing head back to where it was before though -- do you really need 800 useless commits in the history when you're going to just be adding the code back in sanely later anyway?

Reverting them seems a bit more risky to be than just rebuilding it properly -- you'll need to write some scripts to make sure you got all the commits and then the whole dev team is going to end up pushing commits which unrevert your reverts just so you can then rebase the feature branch..

Sometimes push -f is the best option ;)

But not in this case, a force push is not needed.

Depends on the situ really; if it got people working again faster (yay, saved money!) or if production was unavailable and it helped get things back up faster (yay! more business!) then it'd be the right move in my book -- otherwise, yeah, it's a horribly hacky thing to do and shouldn't be done unless you really have to...

I'm not saying I would have done one or the other if I was the OP -- just that I'd have no issues doing it should the situation call for it and it saved time/money at the cost of pure feelings :}

Agreed. He has the following to say:

>The easiest strategy in a case like this is usually to back in time: If the problem was caused by the unorthodox checkout-add-commit, then reset master to the point before that happened and try doing it a different way. That strategy wasn't available because X had already published the master with his back-end files, and a hundred other programmers had copies of them.

So resetting the commit isn't an option, but what about reverting it? It seems like the obvious alternative to me, I'm not sure why he didn't mention it.

Reply on news.ycombinator.com