[speaking obviously as non-committer, just offering a perspective] A potential factor to consider: If one knows that all work in topic branches end up merged without anyone first rebasing to clean up, you now have a constant trade-off between history readability and committing often. I personally dislike anything that causes there to be a reason *not* to commit. I'd much rather commit like crazy and clean it up before merge, than maintaining additional branches privately just for the purpose, or playing around with stashes.
I.e., in addition to the effects on history, if people feel it does make history harder to read, it presumably affects the behavior of those people in day-to-day work in terms of their propensity to commit. If the issue is not rebasing public branches, one can presumably always introduce a convention whereby work happens in branch X; and if rebasing is needed, you do that in X/rebased/1. If a further iteration ends up happening, X/rebased/2. Or something along those lines. This would get you: * History looks the way you want it to look. * All original history is maintained if you really want to look at it (I *do* think it could be useful when diving into a JIRA ticket after the fact to figure out what reasoning was). * You're not rebasing published branches. The downside I suppose is that the branch count increases. -- / Peter Schuller (@scode, http://worldmodscode.wordpress.com)
