Sorry, knode fails me again. Some keyboard shortcut must be too close to ctrl+v for me...
Stephen Kelly wrote: >> Either way is an assumption, but only one of these assumptions involves >> deliberately discarding data. ;) If noise is data, you would have a good point. >> >> What specifically do you mean by "creating useful history" though? i.e. >> what should be done additionally in a rebase workflow to get the useful >> history you refer to? > > Do this: > cd /tmp git clone git://gitorious.org/grantlee/grantlee.git cd grantlee git remote add mjansen git://gitorious.org/~mjansen/grantlee/mjansen- grantlee.git git fetch mjansen gitk --all Now look at the commits in the experimental branch from mjansen (before v0.1.5). See that some commits do lots of things at the same time/in the same commit and should be split. There's also commits for s/todo/TODO/, fixing copyrights etc. Having those in separate commits is not 'useful historical data'. There's also a workaround for a bug in the 0.1 branch which I eventually fixed. The 0.1 branch was then merged into experimental and the workaround removed. Speaking as the person who reviewed the branch, this and the large commits issue made it harder to review. I had to navigate around the merges in my head. mjansen might just have been following a 'never rebase public branches' philosphy, but that really doesn't work for me. It was a complicated feature requiring lots of refactoring. When issues crop up I want to know if it was refactoring that introduced the issue, or the feature itself. I don't want to be looking back over the commits 6 months from now, find the workaround, find the merge and removal of the workaround, dig into the 0.1 branch to find out what the actual fix was, find it wasn't relevant to the issue I'm trying to diagnose etc. That's why the information conveyed by the 'actual history' is only noise that increases maintenance burden and reviewability. If your topic branch introduces something and then fixes it 5 commits later, then squash the fix into the introduction and add a commment. A comment is a bazillion times more visible than a hunk among many unrelated hunks in a large commit in a long lived and then merged branch. Look at the history of the actual repo between 0.1.6 and 0.1.7. Small commits. First refactoring to make room for feature, then the feature. It should be impossible to split a commit into two unrelated commits. At least I try to stick to that in grantlee.