4 ms·

squash merges to master are terrible for those that want to go looking why a certain change was introduced. Now a larger change set is hidden behind a squash m

squash merges to master are terrible for those that want to go looking why a certain change was introduced. Now a larger change set is hidden behind a squash merge, and why was line 50 in foobar.py updated? Who knows, it was part of this giant merge request which no longer provides context why the developer changed line 50 in foobar.py. Commit messages should explain why the change was made to the code. The amount of times that I go diving into a codebase only to find that the change was introduced in a larger commit that just says "fix bug" with no further information is maddening.

jasonpeacock 6y ago
You're describing the wrong use of squash merges, and I agree they suck. The right use is to allow me to make crappy, random commits on my own feature branch, clean them up those commits when I'm ready to release the change. And the commit description will describe what's going on. The key is that my feature branch is not long-lived - only a day or two, long enough for me to make a step forward before merging it back into mainline and then starting on the next step.
- w0utert 6y ago
  If you do this for short-lived feature branches only, why do you even need to squash merge for this? What I typically do for such things is to have a WIP commit that I amend and force push while working on the feature, then when everything is ready to merge I reset —-soft and make separate commits for each part of the work that can be compiled and tested indivually, rebase onto master and then fast-forward merge.
  - yawaramin 6y ago
    I think you just answered your own question. Compared to your workflow, the squash-merge workflow allows: - Commit and push naturally as you work - Reviewers to look at individual commits separately after having already reviewed previous commits - Squash-and-merge with one click (usually, e.g. GitHub) instead of messing around with git resets and branch history.
- ArchOversight 6y ago
  Even for a short lived feature branch that lasts maybe a day or so there may be a bug you find during testing that you quickly fix, or a change you make in existing code to help support the new feature or something you know is coming down the pipeline, and that information is now lost.
  - yawaramin 6y ago
    You can say that about any commit in the repo, no matter how granular the commits are.
  - jmcqk6 6y ago
    Or you could make consideration for tracking that change in source code a priority when making those changes and code appropriately. The problem you describe is a problem because people are not prioritizing or valuing the commit history as a resource. If you fix that, then people will think about these things differently. Squash and merge is not the only way to get things into master. You can rebase and squash commits as needed on your branch and then bring multiple commits from your branch onto master. That takes more advanced usage of git, but learning that makes sense once you start really valuing the history.

jasonpeacock 6y ago

You're describing the wrong use of squash merges, and I agree they suck. The right use is to allow me to make crappy, random commits on my own feature branch, clean them up those commits when I'm ready to release the change. And the commit description will describe what's going on. The key is that my feature branch is not long-lived - only a day or two, long enough for me to make a step forward before merging it back into mainline and then starting on the next step.

w0utert 6y ago
If you do this for short-lived feature branches only, why do you even need to squash merge for this? What I typically do for such things is to have a WIP commit that I amend and force push while working on the feature, then when everything is ready to merge I reset —-soft and make separate commits for each part of the work that can be compiled and tested indivually, rebase onto master and then fast-forward merge.
- yawaramin 6y ago
  I think you just answered your own question. Compared to your workflow, the squash-merge workflow allows: - Commit and push naturally as you work - Reviewers to look at individual commits separately after having already reviewed previous commits - Squash-and-merge with one click (usually, e.g. GitHub) instead of messing around with git resets and branch history.
ArchOversight 6y ago
Even for a short lived feature branch that lasts maybe a day or so there may be a bug you find during testing that you quickly fix, or a change you make in existing code to help support the new feature or something you know is coming down the pipeline, and that information is now lost.
- yawaramin 6y ago
  You can say that about any commit in the repo, no matter how granular the commits are.
- jmcqk6 6y ago
  Or you could make consideration for tracking that change in source code a priority when making those changes and code appropriately. The problem you describe is a problem because people are not prioritizing or valuing the commit history as a resource. If you fix that, then people will think about these things differently. Squash and merge is not the only way to get things into master. You can rebase and squash commits as needed on your branch and then bring multiple commits from your branch onto master. That takes more advanced usage of git, but learning that makes sense once you start really valuing the history.