The real problem here is:<p>... "and I was getting ready to commit a series of important changes" ... Before doing so, I want to merge in the recent changes from the remote master, so I do the familiar git pull. ... "maybe I’m going slightly crazy after 3 days straight hacking" ...<p>Do I interpret this correctly as that the author has not commited any changes for 3 days?<p>With SVN there may be an excuse for this, but with Git the right way is to commit as often as possible, and then squash your commits before pushing them. With such a workflow the problem would have been a non-problem - just use git reflog and checkout your previous version.<p>Of course you wouldn't use a git pull then, but just rebase your local commits on top of master.<p>Learn how to use your tools, instead of complaining about them!
The article isn't as anti-git as the title might lead you to believe. I enjoyed the article for the research and up-voted it. I use and like git, but the ideas of silent data loss is scary (as it spreads).<p>Long story below.<p>However, if you want real fun try out what one centralized repository did for me once. I was (against my will) using Visual Source Safe in the 1990s (ick ick ick). Visual Source Safe at the time represented its data on a server with two RCS style history files (called a and b). When you committed both of these were updated (no idea why there were two) and then as a matter of policy Visual Source Safe re-wrote your local content from the repository. That is on a check-in: it wrote back over your stuff. Fast forward to the day the disk filled up on the server and a single check-in attempt corrupted a and b (so even if redundancy was the reason for 2 file, it didn't work) and the the server stayed enough up to force overwrite my local content. Everything lost for the files in question (no history, no latest version, no version left on my system, forget about even worrying about recent changes). Off to tape backups and polling colleagues to see if we could even approximate the lost source code.
My ears perked up when I heard that it involved renames on OSX. I don't know about the exact issue he had, but I recently found out the hard way that OSX's HFS+ is a case-insensitive* filesystem. You can get subtle issues by importing multiple files with the same case (such as "README.txt" and "ReadMe.txt") into the same repository; this isn't specific to git.<p>I had a similar issue with Perforce on Windows - Perforce was case sensitive, Windows wasn't, and thanks to CamelCase, there were two files that had the same letters but different casing. (I don't remember the names.)<p>* Technically, "case-insensitive but case-preserving", which in practice seems to mean, "case-sensitive, <i>except when you need it to be</i>".
"OK, so the bug never trigged in 16,000+ Linux kernel merges."<p>If your team is avoiding a tool with a 1 in 16,000 chance of failure then they'd probably also want to avoid flying (1 in 20,000 chance of death by failure), large bodies of water (1 in 8,942) and run terrified from cars (1 in 100) (source: <a href="http://www.livescience.com/3780-odds-dying.html" rel="nofollow">http://www.livescience.com/3780-odds-dying.html</a>.<p>The car stat seems rather high, and git won't kill you, but the general point is that a 1 in 16,000+ chance of losing a few hours of work is "s--t happens, find a workaround and get over it" odds.
> Before doing so, I want to merge in the recent changes from the remote master, so I do the familiar git pull. It complained about some files that would be overwritten by the merge, so I saved a backup of my changes, then reverted my changes in those specific files, and proceeded.<p>Yikes. git stash / git stash apply. Pulling into a dirty working tree is asking for trouble.<p>git losing data is Very Very Bad (and <i>massive</i> kudos to the author for tracking down the bug rather than just bitching about it), but if you're following a proper git workflow (pull to clean working trees, save often), you shouldn't ever be in a position to trigger this bug. That's not an excuse for git to break like that, but the reason that it was likely never seen in the 16k Linux commits is that it's not the "right" way to do things.
To quote: <i>OK, so the bug never trigged in 16,000+ Linux kernel merges</i>—kernel developers are probably sane people quite proficient in git so that's quite unlikely to happen. That's probably the reason the bug was out there for a year, nobody ever bumped into it. I would bet some money on none of them kernel developers ever having git-pulled into a dirty working tree. (Most of the newbies around the world who probably bumped into it didn't understand git was in error there—excluding the author.)<p>I can't explain why the opposite happens. Most of the people I know intuitively commit or stash their local changes before merging. They have this intuition even if git is relatively young piece of software. But then there are always a handful of people that I imagine who could do something like that. And I'm not quite sure <i>why</i>.<p>One possibility is that it could come down to the level of trust in computers. I don't think I <i>could issue</i> git-merge without git-stash/git-commit first—probably because I don't instictively trust programs to handle complex operations too well in the first place. Operations such as handling unsaved data or letting random commits from different place three-way merge themselves into a single branch. <i>Or both.</i><p>This mechanism of distrust might be similar to how drivers who think they're bad drivers are, in fact, the best drivers. They underestimate their capabilities enough to assume everything won't always go right, and then they're a few steps ahead when something goes wrong.
For anyone that's interested, the version of git that fixes this issue (1.7.7) has just been released:<p>Download: <a href="http://code.google.com/p/git-core/downloads/list" rel="nofollow">http://code.google.com/p/git-core/downloads/list</a><p>Announcement: <a href="http://git.661346.n2.nabble.com/ANNOUNCE-Git-1-7-7-tc6849424.html" rel="nofollow">http://git.661346.n2.nabble.com/ANNOUNCE-Git-1-7-7-tc6849424...</a>
I'm really late to this party but I want to stress a. Point that doesn't get mentioned often enough:<p>Do not use "cp". Please.<p>Copying changes to save them and reapply later is nearly guaranteed to quietly lose changes, reintroduce removed code, or otherwise screw up your work.<p>If you want to move changes stash them or commit them and then apply them elsewhere. Using cp throws out all of git's ability to help you do what you mean and not what you say.<p>Also, the data corruption was caused by a bug, yes, but the cp based workflow being used will result in a nasty suprise sometime in the future.
That's kind of an odd response to a bug - not adding a new test, but just noting that it didn't hit one particular project. Is Git's entire test-suite just 'the Linux kernel changelog'?
Even if you choose to keep three days worth of changes uncommitted, you're still doing local backups of your machine anyways, right? He'd be facing the same amount of information loss if his hard drive died.<p>If you're on OS X, Time Machine will get you back to where you were recently (except if your home directory is encrypted, then it backs up on logout). Or use Dropbox/SpiderOak/other to keep the last <i>n</i> versions of your changes.
At first, it seemed that this was another rant about a misbehaving piece of software.<p>But I was impressed that, unlike so many others (myself included), the author went beyond just complaining. He actually made a real effort to identify the conditions under which the issue occurs. But I was blown away when he actually examined the source code and identified when the bug was introduced. Great work!
Its good to know that my 'feature development' git flow would make sure that this bug would be avoided or at the very least easily worked around.<p>My favorite git flow in 143 easy to remember steps<p>1) git checkout -b MyFeatureBranch # create a feature branch<p>2) Code/Hack/Fall Asleep on Keyboard<p>3) git commit -am "Wow finally done with this tiny feature"<p>4) Go back to to 2 if needed<p>5) git checkout master<p>6) git pull # get all the latest changes<p>7) git checkout MyFeatureBranch<p>8) git rebase -i # squash commit comments if neccessary<p>9) Fix merge conflicts, git add, then git rebase --continue<p>10) git checkout master<p>11) git merge MyFeatureBranch<p>12) git push<p>13) PROFIT!!!<p>This is borrowed from <a href="http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html" rel="nofollow">http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-te...</a>
I suspect that certain types of people (including myself, at times), actually want continuous backups being taken on the state of their working copy prior to actually performing a commit. Bugs or not, Git doesn't do very well with unversioned changes: an accidental 'git reset --hard' can easily blow out lots of work (happened to me), even if that was exactly what the command was supposed to do. The correct thing to do is commit early and commit often (git commit -am "Wibble"; git reset HEAD~ works well for me) but from a user experience standpoint this ought to be automatic.
I admit I skimmed through the article, but, "git destroyed my data" .. hum ... how come ?<p>Git is a versioning system that doesn't free you of making backups of your central master. And by master I mean the global central reference repository or whatever you call it.<p>So you screw up your repository using an unconventional workflow and now you and your co-worker don't trust git anymore ?<p>Well maybe you shouldn't have blindly trusted it in the first place. It's a better tool than many but still is just a tool you should use with care. As any tool. It has bugs.<p>That said, I feel your pain. Finding bugs in other tool can be a very frustrating experience. Well, shit happens :-)
Git can be a beast conceptually speaking if you don't learn it the right way. This was undoubtedly a bug but the author's story surfaced some suboptimal git habits.
The way I avoid problems like this is:
1 - Always do new work in a branch off whatever branch you plan to commit to eventually.
2 - commit often
3 - Use rebase -i to squash commits when everything is looking good
4 - Use rebase parent-branch to replay your commits on top of whatever new stuff is in the parent and resolve any conflicts
5 - Only then go back and merge the working branch back into the parent-branch
cool article about tracking down a bug in git.<p>But this is really a small corner case and I can see how it went unnoticed for a year.<p>I almost never use 'git pull' (I do git fetch and then "git merge" or "git rebase" depending on the results), but more importantly I never ever use pull when I have changes in my current working repository. I commit, and <i>then</i> I pull or pull --rebase etc. This way I'm <i>really</i> sure that my data is safe as git has a lot of safety features for committed stuff. all files are stored as objects and there is a reflog to help if you loose track of rebased branch etc.<p>Another thing that I sometimes do is 'git stash' before pull/merge/rebase etc. git apply later is also a very safe op.
The biggest issue here is not committing before pulling. Always commit all of your changes before updating your history (either through git pull, git fetch/merge or git pull --rebase).
It's not cool that the guy lost some data, but as he points out - all software has bugs. This is just one more reason to make your commits as atomic as possible - which it sounds like he wasn't doing at all.