> And you'll ultimately have to decide whether you want your codebase to represent a series of physical commits, bits that people happened to type out... or whether it should represent a series of logical changes to the codebase
We're on the same page here, but there's a bit of a deeper point being hinted at, which is that being able to be "physical-series-of-commits" is useful when you're in experimenting-dev/refactor mode, and isn't useful at all for people trying to understand your history. Well, mine's not at least -- it's a lot of shitty diffs and "fuck shit checkpoint" commits that don't live long.
Logical history is basically always useful, but you often want temporary checkpoints for yourself before your changes are going to coalesce into something that represents a logical patch-set.
Rebase, in it's most commonly useful ... use case, lets you tack new incoming history that other people have shared onto history you haven't shared yet. For the people other than you, your changes exist in the future.
History rewriting in general lets you fuck around locally with stuff you haven't shared, making trashy checkpoint commits or whatever you want to do, and clean that all up to represent a logical series of changes for sharing.
In short:
Don't work on tracking branches. Branches are cheap.
Periodically bring in others changes into your work with rebase. Your work isn't public and theirs is, theirs is part of public history, yours is part of future history. Always rebase before bringing your changes back into the tracking branch, and then merge your changes into the tracking branch. Often, the history cleanup I want to do is handled by merge --squash, bundling up the change I'm pushing as one commit.
You, whoever is looking at my incoming change, care about the fix for bug FOO or feature BAR being completed. You don't care that I made a bunch of stupid typos. If you do, I don't want to work for you unless you care because your doing some sort of awesome stat analysis on typos made by people like me.
We're on the same page here, but there's a bit of a deeper point being hinted at, which is that being able to be "physical-series-of-commits" is useful when you're in experimenting-dev/refactor mode, and isn't useful at all for people trying to understand your history. Well, mine's not at least -- it's a lot of shitty diffs and "fuck shit checkpoint" commits that don't live long.
Logical history is basically always useful, but you often want temporary checkpoints for yourself before your changes are going to coalesce into something that represents a logical patch-set.
Rebase, in it's most commonly useful ... use case, lets you tack new incoming history that other people have shared onto history you haven't shared yet. For the people other than you, your changes exist in the future.
History rewriting in general lets you fuck around locally with stuff you haven't shared, making trashy checkpoint commits or whatever you want to do, and clean that all up to represent a logical series of changes for sharing.
In short:
Don't work on tracking branches. Branches are cheap.
Periodically bring in others changes into your work with rebase. Your work isn't public and theirs is, theirs is part of public history, yours is part of future history. Always rebase before bringing your changes back into the tracking branch, and then merge your changes into the tracking branch. Often, the history cleanup I want to do is handled by merge --squash, bundling up the change I'm pushing as one commit.
You, whoever is looking at my incoming change, care about the fix for bug FOO or feature BAR being completed. You don't care that I made a bunch of stupid typos. If you do, I don't want to work for you unless you care because your doing some sort of awesome stat analysis on typos made by people like me.