I read this and went "oh good, it's not just me then."
I will occasionally get my copy of a git repo into a state such that the quickest thing to do is not to understand and repair what happened, but wipe the repo and clone afresh. I know this is Wrong and I should Understand it ...
And goddamn. Who thought "Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean" was a good idea WHEN IT'S A DAMNABLE LIE?
I have successfully preached version control to managers before - non-geeks who nevertheless work with documents all day. "Have you ever spent three days editing the wrong version of a document?" and of course they all had. Their eyes lit up at the prospect of a way out of that. That was in 2001. Why don't we have that yet? EDIT: I don't mean the technical side of doc files - solving the blobs issue won't solve the fear issue, per this paper. That's the problem I mean.
david gerard, if I could upvote your comment a thousand times, I would. Especially this:
"Who thought "Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean" was a good idea WHEN IT'S A DAMNABLE LIE?"
I use git because everyone uses git, but I wish the tech industry had consolidated its use around a version control system with an easier-to-understand API. Especially when it comes to "undo". For desktop software, I can just hit Command-z, but git has a complicated syntax, and it is course grained -- per commit rather than per file, and then there is the issue of whether the files have been pushed to the repo yet, or not. To me, the whole point of version control is to have infinite undo, and a version control system that makes that difficult is a bad version control system.
But the worst thing is probably merges -- I merge in a whole other branch, and want to push the changes from that other branch to the repo, as part of my current branch, but git says that everything is up to date and there is nothing to push -- what the hell is that?
The other day, I used git 1.7 on an old server and I also thought somebody did something wrong when it said there were differences between origin/branch and branch but there weren't any. But on modern git this should be good.
Because of the way most non-text files are encoded, it's nearly impossible to collate changes in the way a VCS requires. At work we're using a graphics engine which stores layout data in binary blobs, then exports those to XML(Don't ask me why, I don't know). As a result, you would have to use their IDE tool to perform any merges, and because of that you can't annotate/blame the file at all, which eliminates a lot of the usefulness of the VCS as a repository of history.
When companies start shipping real comparison tools for their binaries then you might see more widespread adoption.
> Their eyes lit up at the prospect of a way out of that. That was in 2001. Why don't we have that yet?
The companies making word processors make word processors. They don't make revision control systems. They don't make document management systems.
It's a failure of vision. Their vision is narrow, and doesn't match their customers work-flow.
Sure, Word has "track changes", but it doesn't have "merge two documents". Because that problem is hard, and the word processor people have no idea how to solve it.
The revision control people look at diff'ing binary files, and go "bleah, use text". So revision control systems don't work for binary blobs like Word files.
If you could extract the changeset from that then you would be well on your way to supporting version control in Word. One problem I've seen is that people tend to conflate version control and document control, and so they end up using version control systems to prevent revisions to documents, rather than to collate revisions to documents into a history.
But Word does have the ability to merge two documents. And you can even configure VCS clients like TortoiseSVN to launch Word as the merge tool for .docx files.
I will occasionally get my copy of a git repo into a state such that the quickest thing to do is not to understand and repair what happened, but wipe the repo and clone afresh. I know this is Wrong and I should Understand it ...
And goddamn. Who thought "Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean" was a good idea WHEN IT'S A DAMNABLE LIE?
I have successfully preached version control to managers before - non-geeks who nevertheless work with documents all day. "Have you ever spent three days editing the wrong version of a document?" and of course they all had. Their eyes lit up at the prospect of a way out of that. That was in 2001. Why don't we have that yet? EDIT: I don't mean the technical side of doc files - solving the blobs issue won't solve the fear issue, per this paper. That's the problem I mean.