On 30.04.2015 00:48, Konstantin Boudnik wrote: > These simple rules allow to produce a much cleaner git history, which is > easier to work with, bisect if needed, and in general do any sorts of tracing.
I have to point out that the goal of version control is not to have a "clean git history" but to have an audit trail of what went into the code, when and by whom. Rebase destroys that information. While I can marginally understand people wanting to look nice in public and rebasing stuff in their local repository clones, rebasing anything that's already been pushed upstream is a recipe for disaster (and repository corruption). We quite recently had a case where we could not trace the history of jdk8 backports and therefore could not decide whether they were public domain or GPL. Really, that's a horrible way to do version control. Maybe instead of trying to fudge the history to make it "cleaner", you could consider a different workflow that doesn't involve creating a branch fore every line of code you write. That's a bit like sayin, Oh, I have a hammer, let's go find as many nails as I can, instead of just hammering in those nails you actually need. And use a wrench for the nuts, please, a hammer just ruins them. -- Brane P.S.: Before someone accuses me of an anti-git bias, let me just mention that I've been studying version control workflows for 20 years and writing a version control system for 15 ... this isn't about git, it's about rational development process.
