On Thu, Apr 30, 2015 at 08:05AM, Branko Čibej wrote: > 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).
Never at any point I have advocated that. More over, I have explicitly warned not to do it. The only case for rebases when you - don't need to expose that you did 26 merges with the master branch while working on your fix - this info is irrelevant to anyone - need to squash a bunch of small commits into a set of larger logically separated commits (e.g. per JIRA tickets or something) Any tool can be abused. I am only suggesting that polluting the history with useless merges doesn't help anyone with anything. Cos > 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.
