5 ms·

I see what you mean about the messy mental model, and I do 100% agree that in a well designed system most problems should have one obvious best solution. That s

I see what you mean about the messy mental model, and I do 100% agree that in a well designed system most problems should have one obvious best solution. That said, I'm not sure that's a fair criticism of git. For instance, in this case, as mentioned below, the author of the article should have just reverted the commit where he checked out the files, then done a normal merge. If you're thinking of everything at the commit level, it's pretty much the obvious thing to do. The first obvious thought is to just backtrack (as mentioned in the article), then once you realize that's off the table (since the code is out in the wild) the very next obvious idea is to revert. Revert is what you do when you can't just undo. It's not even as if his commit involved any merges, so the revert is super easy. I guess I just don't agree that experts would have a hard time finding the simple solution - it was the first thought that popped into my head, and I read the article mostly looking for the explanation for why he didn't just do it. While git does provide near complete control, you almost never need to use more than the basics, and it doesn't have to be confusing. EDIT: Just to make very clear why I think the solution is obvious, the first thought that I think will occur to almost anyone is, "if I can just bring the master branch back to its prior state, then I can merge like usual". The beauty of git is if you can form a coherent idea like "bring the master branch back to its prior state" then you can probably do it, and it probably isn't hard. The mistake the author made was to have that thought, and then instead go off down a rabbit hole, and throw out the original simple idea.

jdmichal 10y ago
If you revert, how do you guarantee that the final result is identical to the previously deployed and tested version?
- cyberpunk 10y ago
  He'd need to revert like 400 commits! Woah that's a real messy one. I hope everyone walks away with a feeling that merging 400 commits in what sounds like a CD env is asking for trouble... I'm probably not going to earn extra ninja points here, but in that situation I'd have turned off the deploy jenkins job, force pushed master back to sanity, squashed these commits into a sensible amount in a new branch, rebased it from master and gotten someone (several someones) to go over the pull rq which should be able to merge without conflict. (Fix conflicts in branch!) Maybe you'll have to get your devs to make a new branch locally and cherry pick their stuff back in, but urgh; I think the solution in the article would have taken me ages to RTFM enough to work it out... The lesson here is merge less, more often, or pay more attention when doing evil things like this should you get into that kind of situ...
  - jdmichal 10y ago
    If you don't care about the history, you can just squash the merge. Otherwise, it's not like those commits on the topic branch cost you anything, and they might have important context. I do agree though that my first step would have been merge from master to the topic, or rebase the topic onto master.
- nolemurs 10y ago
  After you merge everything you could just diff the originally committed files against the deployed and tested versions. If there are any differences, then those need testing! Presumably if you're merging a bunch of other changes in anyway, you're going to need to do a bunch of testing in any case, that's just an inevitable result of splitting the deployment into two phases.
artpepper 10y ago
But how do you revert a commit if there were subsequent commits that changed the same files? (If I'm reading the original post correctly.)
- joatmon-snoo 10y ago
  I think grandparent meant a "git revert", which is actually a distinct operation (introduce a commit which is the inverse of a given commit) from resetting a branch pointer.
- nolemurs 10y ago
  Well, in the worst case, you can literally revert all subsequent commits, merge the topic-branch, then reapply the commits. In most real situations you'll probably find that only a small number of commits actually need to be reverted and reapplied, especially if your team is good about having reasonably self-contained commits. If you're concerned about filling the git logs up with noise, you can always do use rebase to combine any revert/re-revert commits into single log entries.

jdmichal 10y ago

If you revert, how do you guarantee that the final result is identical to the previously deployed and tested version?

cyberpunk 10y ago
He'd need to revert like 400 commits! Woah that's a real messy one. I hope everyone walks away with a feeling that merging 400 commits in what sounds like a CD env is asking for trouble... I'm probably not going to earn extra ninja points here, but in that situation I'd have turned off the deploy jenkins job, force pushed master back to sanity, squashed these commits into a sensible amount in a new branch, rebased it from master and gotten someone (several someones) to go over the pull rq which should be able to merge without conflict. (Fix conflicts in branch!) Maybe you'll have to get your devs to make a new branch locally and cherry pick their stuff back in, but urgh; I think the solution in the article would have taken me ages to RTFM enough to work it out... The lesson here is merge less, more often, or pay more attention when doing evil things like this should you get into that kind of situ...
- jdmichal 10y ago
  If you don't care about the history, you can just squash the merge. Otherwise, it's not like those commits on the topic branch cost you anything, and they might have important context. I do agree though that my first step would have been merge from master to the topic, or rebase the topic onto master.
nolemurs 10y ago
After you merge everything you could just diff the originally committed files against the deployed and tested versions. If there are any differences, then those need testing! Presumably if you're merging a bunch of other changes in anyway, you're going to need to do a bunch of testing in any case, that's just an inevitable result of splitting the deployment into two phases.

artpepper 10y ago

But how do you revert a commit if there were subsequent commits that changed the same files? (If I'm reading the original post correctly.)

joatmon-snoo 10y ago
I think grandparent meant a "git revert", which is actually a distinct operation (introduce a commit which is the inverse of a given commit) from resetting a branch pointer.
nolemurs 10y ago
Well, in the worst case, you can literally revert all subsequent commits, merge the topic-branch, then reapply the commits. In most real situations you'll probably find that only a small number of commits actually need to be reverted and reapplied, especially if your team is good about having reasonably self-contained commits. If you're concerned about filling the git logs up with noise, you can always do use rebase to combine any revert/re-revert commits into single log entries.