ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Git practices [Was: Development process]
Date Thu, 30 Apr 2015 06:29:31 GMT
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.

Mime
View raw message