Distrusting git

http://benno.id.au/blog/2011/10/01/git-recursive-merge-broken

by lelf • 13 years ago

8 7 13 years ago

benno.id.au

Piskvorrr• 13 years ago

Interesting...but mostly as the general warning on trust in software, and as a historical memento (Oct 2011).

blueskin_• 13 years ago

If you aren't keeping daily (or better) snapshots, you're doing it wrong. git (or any other such system) isn't a backup any more than RAID is. There's always the possibility of running into some massive bug that corrupts the whole repository, and having the damage get propagated as happened to KDE last year.

jheriko• 13 years ago

OK, so the bug never trigged in 16,000+ Linux kernel merges. Strangely that doesn’t actually make me feel any better.

I remember when I discovered recursive merge. Turned it off straight away. Testing on a specific kind of code base with 16k test cases isn't that much better than 'untested'.

I like merge conflicts - they don't destroy my productivity and make me feel secure that my SCM isn't stepping beyond its bounds - automatic merges are always dangerous, even if they work 99.9% of the time - the time when it destroys two people's works more than makes up for that (this has happened to me with p4v and git in real world scenarios near a deadline).

I've always had a hard time with git though to be fair... but no problems with mercurial. It started with an installer where it was easy to accidentally download the source repo over my metered connection... 'Linux quality software' for sure.

The more I've learned about how git works the more I don't want to use it. :/

olgeni• 13 years ago

"zfs snapshot"

snogglethorpe• 13 years ago

"Person does something stupid, blames tools" ><

In general: commit before you start doing major tree/history manipulation stuff like merging; committing is what makes your data really secure! This is not a subtle point, it's merely common sense, and because of git's "commits are lightweight, local, and amendable" model, there's little excuse not to commit.

[It seems somewhat likely this person was used to subversion, which has much more heavyweight commits and a more limited model, and thus requires doing more stuff while in an uncommitted state. But "like subversion" is not synonymous with "good practice."]

fluxon• 13 years ago

Though it was posted 2 years and 3 months ago, and the article states that the bug was fixed, to me, the interesting parts were tracking down the versions of git that were affected, and demonstrating the need for more rigorous regression test cases in build --test.

diroussel• 13 years ago

interesting.

It re-inforces the need for task branches. And don't merge into uncommited code.

Distrusting git

Related Stories