3 ms·

This post is full of weird non sequiturs and logical fallacies. So what if git doesn't have a single command to 'squash-merge'? It doesn't natively support a '

This post is full of weird non sequiturs and logical fallacies. So what if git doesn't have a single command to 'squash-merge'? It doesn't natively support a 'pull request' workflow either. Code forges build convenience functionality on top of git. If I didn't have the 'squash merge' feature I'd just use an interactive rebase to fixup/squash the branch's commits before doing a fast-forward-only merge, because I don't want a git history littered with meaningless noise. And the 'fewer commits are better so that must mean no commits is best' argument is such an obvious slippery slope fallacy, come on man. Do you seriously think this kind of argument will fly in real life? You are just going to annoy the crap out of everyone. We don't squash and rebase because we want fewer commits, we do it because we want fewer meaningless noise commits. Do you want to preserve all your editor keystrokes, like backspaces, moving code around, copy-pasting, etc., before committing? If you don't, then you obviously don't want to track any history, right? Of course not, that's silly. That's what your argument is like. I don't want my repo history littered with meaningless noise like these merge commit messages: * Merge pull request #1234 from bob/implement-foo * Implement foo (pull request #1234) The only thing that matters here is the log of the actual work, not the incidental artifact that git merged something. I also don't want a commit history that looks like London's tube system map. Please, keep the history linear so that myself and future team members can quickly focus on the parts that interest them, after just a glance, and don't have to spend time decoding the tangled mess of interlocking branch histories. Much appreciated!

fargle 2y ago
upvoting! "I also don't want a commit history that looks like London's tube system map" i don't care how you do it. squashing? git reset followed by sensible commits? intense ninja-like git commit hygiene? or my favorite, liberal amounts of git rebase -i? the only things i care about are these: 1. your PR contains a series of atomic commits 2. each commit makes a single logical change. 3. that each logical change is adequately described by the corresponding commit comment 4. extra credit if the series of changes is consistent to build and work at each step i don't want to see "ONE" commit per-feature unless it's trivial. i do want to see the development process, but in a "publish"-able form i don't want to see "WIP", "almost working", "fixed broken", "redesigned ...", etc. sausage being made. i especially DON'T want to see patches to files be changed and reverted multiple times as mistakes are made and fixed. the final PR should be you publishing a nice finished series of patches to accomplish a new feature. then! we simply rebase that nice simple series on top of master and merge it with an optional merge commit. this gets you a nice linear history while avoiding the information loss with simply squashing everything in a PR/feature into a single commit.
- lucasoshiro 2y ago
  > London's tube system map Perhaps you live in London, a city with many subway lines and stations that makes many places easy to reach, just like a repository with commits that makes it easy to find where something was introduced. I live in São Paulo, a city 2 times bigger than London but with a smaller subway map. Few places have a subway station near them. Finding the nearest station is only part of the problem, as we need to find a way to go from the station to where we need to be. Just like a repository that uses squash merges.
  - yawaramin 2y ago
    Lol! This is the first time I've seen squash merging be compared to lack of public transit infrastructure :-D
lucasoshiro 2y ago
> I don't want my repo history littered with meaningless noise like these merge commit messages > I also don't want a commit history that looks like London's tube system map. Both sentences starts with "I don't want" followed by aesthetic choices.

fargle 2y ago

upvoting! "I also don't want a commit history that looks like London's tube system map" i don't care how you do it. squashing? git reset followed by sensible commits? intense ninja-like git commit hygiene? or my favorite, liberal amounts of git rebase -i? the only things i care about are these: 1. your PR contains a series of atomic commits 2. each commit makes a single logical change. 3. that each logical change is adequately described by the corresponding commit comment 4. extra credit if the series of changes is consistent to build and work at each step i don't want to see "ONE" commit per-feature unless it's trivial. i do want to see the development process, but in a "publish"-able form i don't want to see "WIP", "almost working", "fixed broken", "redesigned ...", etc. sausage being made. i especially DON'T want to see patches to files be changed and reverted multiple times as mistakes are made and fixed. the final PR should be you publishing a nice finished series of patches to accomplish a new feature. then! we simply rebase that nice simple series on top of master and merge it with an optional merge commit. this gets you a nice linear history while avoiding the information loss with simply squashing everything in a PR/feature into a single commit.

lucasoshiro 2y ago
> London's tube system map Perhaps you live in London, a city with many subway lines and stations that makes many places easy to reach, just like a repository with commits that makes it easy to find where something was introduced. I live in São Paulo, a city 2 times bigger than London but with a smaller subway map. Few places have a subway station near them. Finding the nearest station is only part of the problem, as we need to find a way to go from the station to where we need to be. Just like a repository that uses squash merges.
- yawaramin 2y ago
  Lol! This is the first time I've seen squash merging be compared to lack of public transit infrastructure :-D

lucasoshiro 2y ago

> I don't want my repo history littered with meaningless noise like these merge commit messages > I also don't want a commit history that looks like London's tube system map. Both sentences starts with "I don't want" followed by aesthetic choices.