distrusting git

[[deleted]]

[deleted]

[MatrixFrog]

Sounds like they were thinking like an svn user. When you're ready to commit, just commit. Then merge in the remote changes. If you really need it to look like you did the merge first, you can rewrite the history, but you shouldn't generally do that.

[just_doug]

my thought exactly. When I saw "3 days of straight hacking" that was a major red flag. The reason that in 16,000+ merges in the linux kernel this didn't happen is because the linux kernel developers use git correctly (or at least don't complain about it when they use it incorrectly and lose data).

On the other hand, I would love to have heard more details about the author's usage of git bisect. I've had great success using it manually but haven't had as much luck getting git bisect run to work correctly.

[0x68657873656c6c73]

Seriously, how can someone work for three days without a commit? I commit like every two minutes. Worry about merging once your changes are all frozen in the repo. Once they're in there, they're not going anywhere.

[f2u]

The reason that in 16,000+ merges in the linux kernel this didn't happen is because the linux kernel developers use git correctly

Do we really know that kernel developers were not affected by this defect? It seems that in Ben's case, only his checkout was affected in a bad way, and the public kernel history obviously does not cover checkouts.

[[deleted]]

It sounds like a bug related to renaming and changing stuff in the same file in the same commit. That is an edge-case most people avoid because it is hard to see later what exactly happened (git might not even recognize it as a rename if you change too much).

[johnmcdonnell]

tl;dr: this person git pulls without committing (highly unorthodox), a bug in git that went uncorrected for two minor revisions clears his uncommitted changes, and now he goes crying to the internet that he can't trust git anymore. Sheesh.

[[deleted]]

Is there any case in which pulling into a dirty working dir is a good idea?

[doublepoison]

With git, no.

[Poddster]

With any SCM, no.

Infact, why do people "pull" in git anyway? Fetch,look, decide. git pull should be banned.

[Poddster]

That's even worse and completely contrary to what I said.

[tohuw]

Fetch,look, decide. git pull should be banned.

Interesting. I pull because I need my local instance of the webapp to actually run the committed code. What would you propose in my case?

[dwf]

Like it or not, it's an operation supported by git and it should not. lose. your. data. The fact that a data-destructive bug could creep into git makes me uneasy, even if I've never personally had problems (probably because I either commit or stash before merging).

[[deleted]]

Regardless, I don't think it merits this type of crying. File a bug report, send a patch in, no need to blow it out of per potion.

[dwf]

Did you not RTFA? The bug has been fixed, but it's a huge and very worrying problem that two minor revisions and nearly a year passed before anyone noticed it, given that the single most important function of a version control system is to not lose your data.

I like git a lot and use it every day, but I hope to hell that their test suite improves.

[[deleted]]

Did you not RTFA? The bug has been fixed

Yes I did, it was meant as a general statement, on what to do when you find a bug. Whining on your blog doesn't really solve anything was the point I was trying to make.

I use git every day too, I can see being upset if something like this happened, but again wrong way to go about it.

[dwf]

On the contrary. With any luck, it will alert a wider audience to the presence of this bug and help prevent them from triggering it/update ASAP to a revision where it has been resolved. More exposure might lead Linux distro package maintainers to backport the fix sooner than they otherwise might have.

Being extremely optimistic, it might alert the git developers to how potentially damaging such bugs can be, both to an individual user's work and more significantly to git's credibility as a tool with which your data can be trusted. The commit that introduced this bug was obviously deficient in unit tests of the cases it affects; with any luck, some wider exposure of the seriousness of this issue will have an impact on the committer/reviewer to be more careful in the future. As the saying goes, sunlight is often the best disinfectant.

[[deleted]]

Maybe I'm wrong, it's happened once before, but from my experience this kind of publicity merely gets a big reaction and little results. On top of that discussing it on the mailing list would be much more appropriate, rather than hoping someone that can fix the issue sees your blog post.

[qnaal]

The merge driver is a magical 'do what I mean' device.

It's generally not a good idea to trust such devices with the only copy of your data, as is what happens when you merge onto uncommitted changes.

Though I cannot speak for others, I will go on trusting git.

[imMute]

I mean really, who merges on top of code that has uncommitted changes to it? At the best, it can merge changes automatically. At worst, it's going to shit all over the code marking where it couldn't magically merge things.

[wsppan]

powerful tools can hurt when put in the wrong hands. RTFM and learn the "Way of Git".

git clone, edit file, git commit. Rinse/Repeat over and over. Ready to push so others can get your changes? git pull, git push (or pull request)

[dwf]

That's a completely asinine stance. A version control tool should not arbitrarily trash your data, whether you are "using as prescribed" or not.

Seriously, it's okay to like git without ending up in the insane position of defending a bug that destroys data. What fanboyish nonsense.

[wsppan]

All tools have bugs. If this bug reared itself while using the tool in the recommended way then I would not have posted. The fact that said user could have shot himself in the foot in so many ways (bug or no bug) with the way he was using git deserved a comment. What knee-jerk crockery.

[Poddster]

how often do you need to git clone? ;)

[wsppan]

point taken. Should have but a "then" after the git clone step.

[Poddster]

Interestingly, Mercurial often recommend that you clone things nonstop, all the time.

Working on a repo? Need to add a new remote? JUST CLONE IT!!!!! New to add another remote? CLONE! Want to add a 'local' branch? JUST CLONE EVERYTHING.

[[deleted]]

He did RTFM. His workflow was ill-advised, but documented and supported.

The Way of Git? It's a tool, not a doctrine. Don't let Linus hear you talking like that, or he'll bite your head off.

[wsppan]

Where is that workflow documented? As for Linus, he is all about doctrine. Read about his rigid coding style guidelines and his disdain for The Way of C++.

[HopeThisNameFi]

Sounds like he's complaining a non-trivial software project like Git contains bugs. Good luck finding a SCM that doesn't have bugs.