4 ms·

I disagree with your disagreement. Rebasing/squashing can really help clean up the development history and actually make it a ton more useful as a historical re

I disagree with your disagreement. Rebasing/squashing can really help clean up the development history and actually make it a ton more useful as a historical reference. Like all things in programming, discretion is key and obviously it can be overdone, but anecdotally, I've found that it makes the history so much more useful to lump related changesets together. In short, categoricals like "don't do it, you'll lose history" don't really hold much water for me. Of course it can be over done. But done right, it really is a great feature of git and a god-send on larger projects (check out the actual git source log for an example).

icefox 17y ago
I would have to second this. I will almost always squash (or split) commits in a branch before review to have it merged back into the master branch. I try to have each commit do a specific individual task. While adding docs to the api could be a separate function (just because you did it last) I would rather have that squashed so in two years when you are looking at the new function you see the api docs that go with it. This doesn't mean everything should be in 1 commit and it also doesn't mean 30 commits. Common sense plays a big role here.
santry 17y ago
I'm with you. One of the great things about git and its ability to 1) easily branch and 2) rewrite history is that I can go down a certain path in a feature branch, realize I need to approach it differently, make mistakes, fix those mistakes but still commit a clean patch for public consumption.
mullr 17y ago
I'm with you 100%. Before publishing my changes I always rebase -i origin/master and edit the history, keeping in mind consistency, usefulness in the history, and the poor guy who has to review my changes before they hit mainline. (we use gerrit) Thinking of it in terms of code review is actually very helpful; I find it leads to very clear, self-contained commits with good comments.

icefox 17y ago

I would have to second this. I will almost always squash (or split) commits in a branch before review to have it merged back into the master branch. I try to have each commit do a specific individual task. While adding docs to the api could be a separate function (just because you did it last) I would rather have that squashed so in two years when you are looking at the new function you see the api docs that go with it. This doesn't mean everything should be in 1 commit and it also doesn't mean 30 commits. Common sense plays a big role here.

santry 17y ago

I'm with you. One of the great things about git and its ability to 1) easily branch and 2) rewrite history is that I can go down a certain path in a feature branch, realize I need to approach it differently, make mistakes, fix those mistakes but still commit a clean patch for public consumption.

mullr 17y ago

I'm with you 100%. Before publishing my changes I always rebase -i origin/master and edit the history, keeping in mind consistency, usefulness in the history, and the poor guy who has to review my changes before they hit mainline. (we use gerrit) Thinking of it in terms of code review is actually very helpful; I find it leads to very clear, self-contained commits with good comments.