3 ms·

I agree with this, as well as the $(git add -p) suggestion, which JetBrains tools make super-duper easy, but my reasoning is not for reverts but for cherry-pick

I agree with this, as well as the $(git add -p) suggestion, which JetBrains tools make super-duper easy, but my reasoning is not for reverts but for cherry-pick. I can count on one hand the number of meaningful reverts I've seen, but have innumerable examples of needs to cherry-pick. I admit that will heavily depend upon the branching style used in the project, but that's my experience

keybored 2y ago
Cherry-pick is the copy-paste of VCS. And although copy-paste in code can work, copy-paste at the version control level itself is suspect if we’re talking about long-term history (why copy the changes of a commit?).
- mdaniel 2y ago
  There is a small distinction between copy-paste, which short of using static analysis tooling is undetectable, versus $(git cherry-pick) which is tracked copy-paste Contrast: git checkout -b feat-1 echo 'awesome change' > README.md git commit -am'fix' git checkout main git checkout -b feat-2 echo 'awesome change' > README.md git commit -am'moar awesome fix' git checkout main git merge feat-1 git merge feat-2 with its cherry-pick friend If one is curious why in the world multiple branches would need the exact same commit, I'm sure there are hundreds of answers but the most immediate one is CI manifests are per-branch so if one needs a change to CI, I would a thousand times rather $(for b in $affected_branches; do git checkout $b; git cherry-pick $my_awesome_ci_fix; done) which will survive those branches re-joining main
  - Izkata 2y ago
    > Merge made by the 'recursive' strategy. There's a few things people think git tracks that it actually doesn't, instead it compares diffs and presents the user with extra information that looks like tracking. The go-to example is renaming files, there is a "git mv" but it doesn't actually track the rename. Git reconstructs the rename when looking at history based on if there was a file removed and a file added in the same commit that are some percentage the same. In this case, if that last line was "git cherry-pick feat-2", it does the same (or at least similar) comparisons as "git merge feat-2", but errors because the user would expect cherry-pick to create a new commit and in this case it won't, instead presenting a message asking the user how to continue.
    - mdaniel 2y ago
      Fine, I may be guilty of "coding in a textarea" and obviously did not actually open a terminal and execute those instructions. But I hope a reasonable person could agree that manually redoing a change to .gitlab.yml over and over is not reasonable, regardless of whether git is smart enough to realize what has gone on or not

keybored 2y ago

Cherry-pick is the copy-paste of VCS. And although copy-paste in code can work, copy-paste at the version control level itself is suspect if we’re talking about long-term history (why copy the changes of a commit?).

mdaniel 2y ago
There is a small distinction between copy-paste, which short of using static analysis tooling is undetectable, versus $(git cherry-pick) which is tracked copy-paste Contrast: git checkout -b feat-1 echo 'awesome change' > README.md git commit -am'fix' git checkout main git checkout -b feat-2 echo 'awesome change' > README.md git commit -am'moar awesome fix' git checkout main git merge feat-1 git merge feat-2 with its cherry-pick friend If one is curious why in the world multiple branches would need the exact same commit, I'm sure there are hundreds of answers but the most immediate one is CI manifests are per-branch so if one needs a change to CI, I would a thousand times rather $(for b in $affected_branches; do git checkout $b; git cherry-pick $my_awesome_ci_fix; done) which will survive those branches re-joining main
- Izkata 2y ago
  > Merge made by the 'recursive' strategy. There's a few things people think git tracks that it actually doesn't, instead it compares diffs and presents the user with extra information that looks like tracking. The go-to example is renaming files, there is a "git mv" but it doesn't actually track the rename. Git reconstructs the rename when looking at history based on if there was a file removed and a file added in the same commit that are some percentage the same. In this case, if that last line was "git cherry-pick feat-2", it does the same (or at least similar) comparisons as "git merge feat-2", but errors because the user would expect cherry-pick to create a new commit and in this case it won't, instead presenting a message asking the user how to continue.
  - mdaniel 2y ago
    Fine, I may be guilty of "coding in a textarea" and obviously did not actually open a terminal and execute those instructions. But I hope a reasonable person could agree that manually redoing a change to .gitlab.yml over and over is not reasonable, regardless of whether git is smart enough to realize what has gone on or not