Subtle Effect of Hidden Dependencies on the User Experience of Version Control [pdf] | Hacker News Reader

Subtle Effect of Hidden Dependencies on the User Experience of Version Control [pdf]

static.googleusercontent.com

29 pointsash22 comments

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.

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

And never the twain shall meet.

Actually, Word does have Merge Two Documents:

https://support.microsoft.com/en-us/kb/306484

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.

Actually, Word had had compare and merge functionality for documents for some time -- at least Word 2002/2003, maybe earlier.

Also, word docs default format since 2007 are OOXML, so text -- though not necessarily line -- oriented diffing and merging should be possible.

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.

I don't mean just that - I mean, you can save flat uncompressed ODTs into git and get most of what programmers get from it.

Solving the blobs issue won't solve the fear issue.

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?

You guys do know about git-extras do you?

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.

A common problem seems to be fear of breaking things. That seems to be the opposite of the purpose of version control systems! I had the same experience using a CAD document management system. I wanted to not only backup the repository but also be able to extract files from it manually, both of which turned out to be very hard. I also kept local backups of files because I didn't trust the overly complicated system. Who knows what switch you might set wrong and destroy other people's work.

My only complaint regarding the "hidden dependencies" is that it is actually a form of "hidden complexities to the problem."

That is, just because you can reduce the problem to a single simple sentence, does not mean that it is a single simple problem. I welcome research into making it simple, but I get worried when that research tends to gloss over many of the different use cases that drove the tools that exist.

Would be like complaining about how many different tools there are to cut things. And, seriously, can you believe that people actually use their butter knives to cut stuff at their dinner tables?! Some people just use the side of their fork!

My question would be along the lines of Alan Kay: is it really complex or did we just make it complicated?

My take would be that there are complications from the myriad reasons these related tasks may be taken. It is possible to have a general purpose tool that works in all cases. It may not be the best performer in all cases, though. Hence, my joke on knives.

My question back, do we have evidence that it is us making it complicated?

I think the things we want to conceptually do at least with code are not that complex, but the tools we have are. I don't know how to prove that without actually building better tools.

One example might be that sync is a complex problem, but Dropbox does a pretty good job of creating a simple tool to manage it. So even if source control is inherently complex, perhaps the tools to manage it do not have to be.

To continue with your utensil example, perhaps we should have one version control system for games, another for individuals and another for small teams rather than trying to make one tool do all those things.

It should be remembered that synchronization among yourself is actually not the source of many (if any) troubles. So, you say that Dropbox makes this easy, but only in the case where there is an understanding that only one person is making edits at a time. As that is the most common case. You put something in a folder for others to look at. Or in a folder so that you can access it somewhere else.

Contrasted with highly collaborative editing where many users are concurrently making changes and want to find a way to present them. Git provides tools not only to manage these combinations and operations, but to reason about and display them.

So, with my knife analogy, using a fillet knife is ridiculously useful if that is what you need. Likely to cause frustration if it is not. And training will help.

Mostly, I'm comfortable with the git CLI workflow (of course, I have often worked as a "lead" before, as well). However, we do use gitk at my current job to visualize the change history tree of a project.

Tools like gitk need a mode to auto-sync their visualization (BUT NOT your workspace) with the "origin", so you can quickly see what is going on in the outside world, as well as your own work, just like you would see in a centralized system. I wonder if gitk has a --show-origin flag or some such thing that I missed?

It's nice to be able to work off-line, but most of us at the end of the day are part of a work-group all trying to complete something together, and need to see the centralized view of project status/history.

For that, I have come to prefer a 'git fetch' workflow over a 'git pull' based one. I don't know what change that will cause in gitk, but otherwise it does basically what you are asking for.

Thanks, I will have to check out using "fetch" next week. I'm not sure what happens if I do a fetch while my workspace already has "master" checked out, but if I have a local working branch checked out, this looks like a safe way to peek ahead at what others are doing before I blindly start merging/pulling.

Tl;dr; tools like ungit provide a better gui then tools like github for mac/windows

The paper doesn't even mention ungit tool.

We have started to work with git about a year-and-a-half ago. Here are some of the lessons I have learned in that time:

1) Get yourself a decent visualisation of the commit graph.

You should see at least:

* Labels for all local branches

* Labels for all remote-tracking branches ("origin/whatever" etc)

* A label for the HEAD pointer (i.e. what is currently checked out.)

I found the Git Extensions plugin for Windows pretty helpful in this regard, though I think gitk and the Eclipse and Intellij visualisations show them, too.

"git log" with default settings does not show anything except your currently checked out branch, which can be extremely confusing.

2) When in doubt, do "git fetch".

This will synchronize the remote-tracking branches on your machine with the actual state of the remote repository. It will not include the changes into your currently checked out copy and it will not modify the remote repository in any way.

Therefore, if you are unsure if your local repository is correctly synced, calling "git fetch" is usually a good (and safe) way to be sure.

3) Be careful with "git pull".

"git pull" is basically an alias for "git fetch; git merge origin/<the branch you have checked out right now>".

However, what this means is that it will synchronize your "origin/..." branch with the remote repository, then immediately try to merge your local work with whatever changes just got downloaded from your repository.

A good analogy for this procedure is "trying to cross a road with your eyes closed": Because you have no way to inspect the changes that you are actually merging in, this can lead to unexpected conflicts and can be relatively counter-intuitive to undo.

If you are not entirely sure about the state of the remote repository, a better workflow is (in my opinion):

* Do a manual "git fetch".

* Inspect the "origin/..." branch using "git log" or a GUI and identify any relevant changes and possible conflicts.

* Do "git pull" or "git merge origin/..." when you actually want to incorporate the changes into your checked-out copy.

4) All the history rewriting stuff creates copies.

Your old commits are still around, they are just not included in any branch and therefore hidden from most GUIs. However, you can still access them by calling any git command with their commit ID.

> this can lead to unexpected conflicts and can be relatively counter-intuitive to undo.

git merge --abort. Perhaps not intuitive, but it's a single command.

Reply on news.ycombinator.com