4 ms·

> If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue I'm firmly of the

by m12k 6y ago

> If I rollout a rewrite of an endpoint and run into a weird issue in the QA environment, I'm a simple git revert away from fixing the issue I'm firmly of the belief that any benefits that squashing brings would be better achieved with better tooling, rather than by re-writing history and throwing away potential debugging information. In this case, what you need is for git to make it easier to revert 25 commits in one go

bluGill 6y ago
If git has a concept of branches like mercurial has it would be a lot easier as you can actually see what branch your commits attached to. (there are pros and cons of both approaches - this is a con of the git approach, I'm not knowledge about enough about esoteric details to comment on if git actually made a bad choice or just a compromise)
- m12k 6y ago
  If you use the standard merge commit message in git, then you can still tell what branch things came from when being merged. As someone that has used both mercurial and git, the trouble with named branches (and having to remember to remove them when merging to master) is one of the reasons why I prefer git.
  - idoubtit 6y ago
    Knowing the name of the branch is not enough to find the commits. With Git, a branch is just a kind of moving tag on the last commit. The problem mentioned in this thread is rolling back a feature that was merged. The only solution I know is navigating the log to find the first commit on the branch from which to revert. Don't forget there may have been several merges from and to master, as well as commits shared with other git branches that should not be reverted. In a Mercurial branch, each commit is tagged with the branch name. Unamed branches, à la Git, are called "bookmarks".
    - nemetroid 6y ago
      > The only solution I know is navigating the log to find the first commit on the branch from which to revert. Don't forget there may have been several merges from and to master, as well as commits shared with other git branches that should not be reverted. The only step necessary to revert the changes from a merged branch is to revert the merge commit. See: https://stackoverflow.com/questions/7099833/how-to-revert-a-merge-commit-thats-already-pushed-to-remote-branch https://stackoverflow.com/questions/7099833/how-to-revert-a-... https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt https://github.com/git/git/blob/master/Documentation/howto/r...
- oauea 6y ago
  Thankfully most Git hosting websites do have this concept. You can revert a PR whole using github, etc
teekert 6y ago
Like a tag? (I'm a git beginner so no sarcasm here, really I'm really interested in this stuff.)
- Aeolun 6y ago
  The problem is if multiple people make other changes after yours. You can certainly go back to your tag, but you lose all their changes as well. If you revert one specific commit it just does another commit with the exact inverse of what happened in the reverted commit, so all other changes are preserved.
wtetzner 6y ago
Also, can't you just revert the merge commit?
- joshribakoff 6y ago
  Yeah but I’m guessing most people commenting don’t know how. It’s: git revert -m 1 <commit> Or something
saagarjha 6y ago
How about the case where I made a commit because I wanted to switch to my laptop and continue working? Why should I keep that around ok my history?
- WorldMaker 6y ago
  It was clearly a natural stopping point in that you stopped working on the code for the amount of time it took to switch. There's nothing wrong with encoding natural stopping points in your commit history, even when those natural stopping points don't always align with semantic stopping points (features/fixes/completed tasks). Sometimes those natural stopping points even encode data you might miss later: sometimes in making that switch you also mentally switch tracks and looking at where you stopped and where you restarted sometimes can remind you of things you forgot in between. I've found debugging cases where that helped me solve problems. (That said, in practice I rarely keep such "natural stop commits" myself, but I've also never been strict about it and sometimes keep them. There's nothing wrong with them and sometimes they are useful "waterline" markers in a larger effort.)
  - saagarjha 6y ago
    I don't make these commits often either, they exist almost exclusively to move code across machines. Actually, I commit much less frequently than most people, keeping most of my work in the staging area for long periods of time until it's ready to be committed. Probably a bad strategy, but it keeps my code clean…
    - m12k 6y ago
      My point is no matter what your commit strategy is, the reality of what actually happened is debugging info, and worth preserving to help debug later. While debugging and digging through history I'm often asking the question "what were they thinking?", and the info that you made a commit just to move to a different machine might make me e.g. consider it more likely that you left something out, or stopped a line of development early because you needed to do the commit earlier than you normally would. Squashing tries to hide the "how" and "in which order" so you only get the "what" of what was developed. But "how" and "in which order" are valuable pieces of information too.
renewiltord 6y ago
git-revert supports ranges if you've used any version within the last couple of years.

by m12k 6y ago

bluGill 6y ago

If git has a concept of branches like mercurial has it would be a lot easier as you can actually see what branch your commits attached to. (there are pros and cons of both approaches - this is a con of the git approach, I'm not knowledge about enough about esoteric details to comment on if git actually made a bad choice or just a compromise)

m12k 6y ago
If you use the standard merge commit message in git, then you can still tell what branch things came from when being merged. As someone that has used both mercurial and git, the trouble with named branches (and having to remember to remove them when merging to master) is one of the reasons why I prefer git.
- idoubtit 6y ago
  Knowing the name of the branch is not enough to find the commits. With Git, a branch is just a kind of moving tag on the last commit. The problem mentioned in this thread is rolling back a feature that was merged. The only solution I know is navigating the log to find the first commit on the branch from which to revert. Don't forget there may have been several merges from and to master, as well as commits shared with other git branches that should not be reverted. In a Mercurial branch, each commit is tagged with the branch name. Unamed branches, à la Git, are called "bookmarks".
  - nemetroid 6y ago
    > The only solution I know is navigating the log to find the first commit on the branch from which to revert. Don't forget there may have been several merges from and to master, as well as commits shared with other git branches that should not be reverted. The only step necessary to revert the changes from a merged branch is to revert the merge commit. See: https://stackoverflow.com/questions/7099833/how-to-revert-a-merge-commit-thats-already-pushed-to-remote-branch https://stackoverflow.com/questions/7099833/how-to-revert-a-... https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt https://github.com/git/git/blob/master/Documentation/howto/r...
oauea 6y ago
Thankfully most Git hosting websites do have this concept. You can revert a PR whole using github, etc

teekert 6y ago

Like a tag? (I'm a git beginner so no sarcasm here, really I'm really interested in this stuff.)

Aeolun 6y ago
The problem is if multiple people make other changes after yours. You can certainly go back to your tag, but you lose all their changes as well. If you revert one specific commit it just does another commit with the exact inverse of what happened in the reverted commit, so all other changes are preserved.

wtetzner 6y ago

Also, can't you just revert the merge commit?

joshribakoff 6y ago
Yeah but I’m guessing most people commenting don’t know how. It’s: git revert -m 1 <commit> Or something

saagarjha 6y ago

How about the case where I made a commit because I wanted to switch to my laptop and continue working? Why should I keep that around ok my history?

WorldMaker 6y ago
It was clearly a natural stopping point in that you stopped working on the code for the amount of time it took to switch. There's nothing wrong with encoding natural stopping points in your commit history, even when those natural stopping points don't always align with semantic stopping points (features/fixes/completed tasks). Sometimes those natural stopping points even encode data you might miss later: sometimes in making that switch you also mentally switch tracks and looking at where you stopped and where you restarted sometimes can remind you of things you forgot in between. I've found debugging cases where that helped me solve problems. (That said, in practice I rarely keep such "natural stop commits" myself, but I've also never been strict about it and sometimes keep them. There's nothing wrong with them and sometimes they are useful "waterline" markers in a larger effort.)
- saagarjha 6y ago
  I don't make these commits often either, they exist almost exclusively to move code across machines. Actually, I commit much less frequently than most people, keeping most of my work in the staging area for long periods of time until it's ready to be committed. Probably a bad strategy, but it keeps my code clean…
  - m12k 6y ago
    My point is no matter what your commit strategy is, the reality of what actually happened is debugging info, and worth preserving to help debug later. While debugging and digging through history I'm often asking the question "what were they thinking?", and the info that you made a commit just to move to a different machine might make me e.g. consider it more likely that you left something out, or stopped a line of development early because you needed to do the commit earlier than you normally would. Squashing tries to hide the "how" and "in which order" so you only get the "what" of what was developed. But "how" and "in which order" are valuable pieces of information too.

renewiltord 6y ago

git-revert supports ranges if you've used any version within the last couple of years.