30 ms·

>I will defend merge squash forever - low effort, good results. You do whatever you want in your feature branch, then merge squash. I completely agree. Trying

>I will defend merge squash forever - low effort, good results. You do whatever you want in your feature branch, then merge squash. I completely agree. Trying to read through the git history of a non-squashed repo is painful, and I actively try to avoid it. Seeing a bunch of commits that just say "fixed typo" is not helpful to me, and I really don't care about seeing someone's workflow or thought process in minute detail as they were developing something.

Ragnarork 3y ago
Same. One side-effect I really like with it is really the complete freedom left to branch authors to do whatever the hell they want with their commits. Want to push your WIPs often? Do it. Want to experiment, commit, rollback, go someplace else, whatever? Do it. No one will care about the process and only the outcome of the end result will matter. And I think it removes one (possibly tiny but still) source of anxiety about how work is perceived by others. The squashed merge commit is the only one that should be properly formatted, have all the checks and validation.
seba_dos1 3y ago
This is a false dillema. Seeing garbage "fixed typo" commits has nothing to do with MRs being squashed or not. Squash merging may be used as a really poor way to clean them up (which happens at a wrong place in the process, leading to loss of actually valuable context), but that's pretty much the whole connection. Don't present garbage commits to review in the first place and you're golden. It improves not just the history, it makes reviews easier and more effective too. The problem with it: it requires some basic Git skills, which is too much for some professionals out there.
earthling8118 3y ago
In most cases those should've been fixup commits and rebased before merging. Squashing isn't necessarily the best tool for this kind of situation.

Ragnarork 3y ago

Same. One side-effect I really like with it is really the complete freedom left to branch authors to do whatever the hell they want with their commits. Want to push your WIPs often? Do it. Want to experiment, commit, rollback, go someplace else, whatever? Do it. No one will care about the process and only the outcome of the end result will matter. And I think it removes one (possibly tiny but still) source of anxiety about how work is perceived by others. The squashed merge commit is the only one that should be properly formatted, have all the checks and validation.

seba_dos1 3y ago

This is a false dillema. Seeing garbage "fixed typo" commits has nothing to do with MRs being squashed or not. Squash merging may be used as a really poor way to clean them up (which happens at a wrong place in the process, leading to loss of actually valuable context), but that's pretty much the whole connection. Don't present garbage commits to review in the first place and you're golden. It improves not just the history, it makes reviews easier and more effective too. The problem with it: it requires some basic Git skills, which is too much for some professionals out there.

earthling8118 3y ago

In most cases those should've been fixup commits and rebased before merging. Squashing isn't necessarily the best tool for this kind of situation.