git workflow draft

[Stephen Kelly]

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.