On Mon, Jan 9, 2012 at 10:02 AM, Peter Schuller <peter.schul...@infidyne.com > wrote:
> [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. > For sure- I think everybody agrees that it's best to rebase private branches for maximum readability/useful history. 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: > Hmm. I haven't seen this done before, but I think it actually might work really well. As a tweak, we could require that discontinued branches (like X and X/rebased/1 in your example) be relegated to tags instead of branches, and under some standard hierarchy, i.e. "refs/tags/discontinued/X", "refs/tags/discontinued/X/rebased/1". The original branches themselves could then be removed. * 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). > +1 on this! * You're not rebasing published branches. > > The downside I suppose is that the branch count increases. > This downside largely goes away if tags are used instead. A possibly larger downside is that if anyone has been basing some work of their own off of branch X, then they would need to rebase their own work on top of the new version, which might not be trivial if they forked off an earlier commit than the last. But people basing important+complicated work on pending ticket work probably should expect some difficulties of this nature. p
