
Subtle Effect of Hidden Dependencies on the User Experience of Version Control [pdf] - ash
https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42942.pdf
======
davidgerard
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
> 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
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.

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

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

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

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

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

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

~~~
ash
The paper doesn't even mention ungit tool.

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

