
Distrusting git - lelf
http://benno.id.au/blog/2011/10/01/git-recursive-merge-broken
======
jheriko
> 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. :/

------
snogglethorpe
"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."]

------
blueskin_
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.

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

------
fluxon
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
interesting.

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

------
olgeni
"zfs snapshot"

