git workflow draft
steveire at gmail.com
Wed Feb 16 23:19:56 GMT 2011
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:
git clone git://gitorious.org/grantlee/grantlee.git
git remote add mjansen git://gitorious.org/~mjansen/grantlee/mjansen-
git fetch mjansen
Now look at the commits in the experimental branch from mjansen (before
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.
More information about the kde-core-devel