4 ms·

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 featurebra

by antocv 10y ago

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.

cyberpunk 10y ago
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 ;)
- antocv 10y ago
  But not in this case, a force push is not needed.
  - cyberpunk 10y ago
    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 :}
aji 10y ago
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.

by antocv 10y ago

cyberpunk 10y ago

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 ;)

antocv 10y ago
But not in this case, a force push is not needed.
- cyberpunk 10y ago
  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 :}

aji 10y ago

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.