4 ms·

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

29 points by ash 11y ago

jauco 11y ago
Tl;dr; tools like ungit provide a better gui then tools like github for mac/windows
- ash 11y ago
  The paper doesn't even mention ungit tool.
deleted 11y ago
[deleted]
Lorento 11y ago
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.
davidgerard 11y ago
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.
- adekok 11y ago
  > 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.
  - jschwartzi 11y ago
    Actually, Word does have Merge Two Documents: https://support.microsoft.com/en-us/kb/306484 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.
  - jameshart 11y ago
    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.
  - dragonwriter 11y ago
    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.
- jschwartzi 11y ago
  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.
Roboprog 11y ago
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.
- taeric 11y ago
  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.
  - Roboprog 11y ago
    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.
taeric 11y ago
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!
- nulltype 11y ago
  My question would be along the lines of Alan Kay: is it really complex or did we just make it complicated?
  - taeric 11y ago
    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?
    - nulltype 11y ago
      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.
      - 11y ago
deleted 11y ago
[deleted]
xg15 11y ago
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.
- sold 11y ago
  > 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.

29 points by ash 11y ago

jauco 11y ago

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

ash 11y ago
The paper doesn't even mention ungit tool.

deleted 11y ago

[deleted]

Lorento 11y ago

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.

davidgerard 11y ago

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.

adekok 11y ago
> 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.
- jschwartzi 11y ago
  Actually, Word does have Merge Two Documents: https://support.microsoft.com/en-us/kb/306484 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.
- jameshart 11y ago
  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.
- dragonwriter 11y ago
  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.
jschwartzi 11y ago
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.

Roboprog 11y ago

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.

taeric 11y ago
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.
- Roboprog 11y ago
  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.

taeric 11y ago

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!

nulltype 11y ago
My question would be along the lines of Alan Kay: is it really complex or did we just make it complicated?
- taeric 11y ago
  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?
  - nulltype 11y ago
    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.
    - 11y ago

deleted 11y ago

[deleted]

xg15 11y ago

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.

sold 11y ago
> 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.