> Thank you, but no. I enjoy working on a branch and committing small changes at a time, sometimes trivial, sometimes not even compiling, sometimes formatting or whatever the hell I feel like. When it comes time to review, I squash all those trivial changes
I understand the workflow you've described here. I think the key word is "trivial". Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes, and that can be really bad for code archeology. When the future me or someone else wants to revisit the history and try to understand why a change was made, it may be buried down a long list of changes in a single commit, and the commit message won't be able to proper explain the reasoning behind it, IMHO.
Something that I also quite like about having individual patches in a PR/MR, is being able to review them individually too. Makes it easier for me, as a reviewer, to be able to understand the motivations behind each set of changes. But then again, that may only apply for larger patchesets/PRs/MRs...
> Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes
Of course not, that would be silly, but who is doing that? I suppose some silly outfits have long lived branches onto which they throw lots of stuff then finally go back to master, but that isn't what this article is arguing about. If I address PR comments, such as typos, simplifying logic etc, this is just noise that doesn't need to be in any history, except maybe for a deep dive by looking at the PR itself.
Yet the article seems to be arguing otherwise and suggesting we use tooling to solve a problem that we don't even have. As someone else said, it is such an engineering nitpick "you're using it wrong" type of article.
We enforce squash commits when we mere PRs to master, and we never have any issues with it.
> If I address PR comments, such as typos, simplifying logic etc, this is just noise that doesn't need to be in any history, except maybe for a deep dive by looking at the PR itself.
Read the rewriting tools references in the text.
> Yet the article seems to be arguing otherwise and suggesting we use tooling to solve a problem that we don't even have.
Read again about the debugging tools mentioned. I never saw a code that needed some kind of debugging. Keeping the history clean makes the debug easier.
You could also say the same about tests. Tests don't solve any problem as long as the code works. But if it doesn't work, test will help to quickly find out where it is broken.
Otherwise, you have no benefit of squashing. If you don't see the benefits of having a commit history, you can use Google Drive instead.
> We enforce squash commits when we mere PRs to master, and we never have any issues with it.
The other comment above would probably also need to transmit a few more objects. At least if you are starting from a commit hash (instead of HEAD) and don't trust the server.
(I would assume git doesn't trust the server, and will verify that the chain of hashes works out.)
Doesn't Git-for-Windows default configure symbolic link support off, though? Or does this exploit work even in that case as long as the underlying file system supports symlinks?
Git-for-Windows may turn symlink support on by default under some specific circumstances. As the repo's wiki [1] says:
Short version: there is no exact equivalent for POSIX symlinks on Windows, and the closest thing is unavailable for non-admins by default unless Developer Mode is enabled and a relatively recent Windows 10 version is used. Therefore, symlink emulation support is only turned on by default when that scenario is detected.
I understand the workflow you've described here. I think the key word is "trivial". Otherwise, when I squash together many "large" patches, the end result will be a huge commit with possibly unrelated changes, and that can be really bad for code archeology. When the future me or someone else wants to revisit the history and try to understand why a change was made, it may be buried down a long list of changes in a single commit, and the commit message won't be able to proper explain the reasoning behind it, IMHO.
Something that I also quite like about having individual patches in a PR/MR, is being able to review them individually too. Makes it easier for me, as a reviewer, to be able to understand the motivations behind each set of changes. But then again, that may only apply for larger patchesets/PRs/MRs...