With that I mean that in KWord I tend to work on a feature by first
writing a unit test and committing that. After that I start to implement
the feature until it actually passes the unit test and after that I add
UIs etc etc etc.
In other words; it takes me a week with 30 commits before I finish this
new feature. And finish naturally doesn't mean bug-free.
During this time I will surely find bugs in other pieces of code, or
simple little features to add there. I commit those separately.
All the above goes into one git tree and depending on how much I work with
others on the features I publish that git tree. But the small fixes will
be committed to the 'release' tree (aka svn) as soon as possible.
At the end of the week when my feature is 'done' I will also push that
upto the release tree.
So, what IMOHO you, as a svn user, will end up with is the trunk that
doesn't have half finished features that mess everything up. You will
still see the current development (mostly) but not the dirty
work-in-progress-excuse-the-mess versions.
As an example; in Krita we have this excellent GSoC project for color
mixing, the author programs in trunk and thus commits everything there.
We have had a couple of times when his commits made it hard for others to
try out his work. I.e. it was quite broken. I'm all for experimentation
so I'm not complaining. But at the same time I do see it as a great
opportunity for Git where I can imagine him committing his
work-in-progress that is known to create regressions and publish that for
other interrested people to see. And only after a week of hacking commit
his updated version to the release tree so everyone can enjoy it.
leaving the release tree free from major regressions.
