git "too hard to use"? [LWN.net]

git "too hard to use"?

Posted Feb 26, 2010 20:11 UTC (Fri) by mikov (subscriber, #33179)
In reply to: git "too hard to use"? by cmccabe
Parent article: Hg Init: a Mercurial tutorial

Wrong and wrong again.

This is a good example of the kind of naivete that doesn't actually help
people use Git in the real world

The people I am referring to are not 'software developers'. I mentioned
documentation writers, testers, web designers, etc. They don't need and
_don't want_ to manage branches. Yet, every git-pull is potentially a merge
and git-rebase requires understanding of what commits are, the relation
between hashes and commits, etc.

Take the following example error message, which while technically very
meaningful, would be utterly confusing to them:

"error: failed to push some refs to '....'
To prevent you from losing history, non-fast-forward updates were rejected"

Refs? non-fast-forward? WTF?

Whether they have been 'damaged' by using 'inferior VCS' is
questionable, but regardless, they are what they are, and they may be fully
competent at their respective jobs without understanding Git or knowing
what a SHA hash is.

From experience, the lock-modify-unlock model and Visual Source Safe
specifically, is the best VCS for non-developers. They really really like
that by default a file can be checked out and modified only by a single
person.

I am thinking that the right solution to this kind of problem may be to
develop reverse bridges. A bridge from Git to SVN, or from Git to VSS. So
that the main repository can be kept in Git, but parts of the team can
interact with it through the safe environment of "lock-modify-unlock".

(Log in to post comments)

git "too hard to use"?

Posted Feb 26, 2010 23:29 UTC (Fri) by ldo (subscriber, #40946) [Link]

mikov wrote:

The people I am referring to are not 'software developers'. I mentioned documentation writers, testers, web designers, etc. They don't need and don't want to manage branches.

Yes they do. Since when do documentation writers not need to manage revisions to their documentation?

Yet, every git-pull is potentially a merge and git-rebase requires understanding of what commits are, the relation between hashes and commits, etc.

What are they doing using rebase? You should never use that on a branch that has been published for others to see.

From experience, the lock-modify-unlock model and Visual Source Safe specifically, is the best VCS for non-developers. They really really like that by default a file can be checked out and modified only by a single person.

Thats not how the real world works. Even with common-or-garden office documents, its common for them to be passed around to different people who will make comments and submit annotations, all of which have to be collated and reconciled together somehow. A distributed VCS merely formalizes the process. The more complex the documentation, the more important such formalization becomes.

Concepts of branches, tagging and merging are common to all modern version control systemstheres nothing specific to Git about any of them. Whats different about Git is the fact that your entire commit history is nothing but a DAG, and branches and tags are just pointers into that DAG.

git "too hard to use"?

Posted Feb 27, 2010 0:23 UTC (Sat) by mikov (subscriber, #33179) [Link]

> Yes they do. Since when do documentation writers not need to manage
> revisions to their documentation?

They don't want to create and manage branches. They want to work on
branches others have created. However in Git creating a branch is often
implicit or required in ordinary work-flow, which makes it confusing for
people.

> What are they doing using rebase? You should never use that on a branch
> that has been published for others to see.

This is not the place and time to explain how Git works, but in short, if
you don't want to create an implicit branch when pulling, you have to do a
"git-pull --rebase". Rebasing is an essential activity when maintaining
your local repository, but it can also be confusing to non-technical
people.

> Thats not how the real world works. Even with common-or-garden office
> documents, its common for them to be passed around to different people
> who will make comments and submit annotations, all of which have to be
> collated and reconciled together somehow. A distributed VCS merely
> formalizes the process. The more complex the documentation, the more
> important such formalization becomes.

I am sorry, but that it is nonsense. It is impossible to merge binary files
like .DOC, .PDF, artwork, etc. Those ate precisely the type of documents
that non-developers need. Branches are actively harmful to them.

> Concepts of branches, tagging and merging are common to all modern
> version control systemstheres nothing specific to Git about any of
> them. Whats different about Git is the fact that your entire commit
> history is nothing but a DAG, and branches and tags are just pointers
> into that DAG.

I am not interested in Git advocacy. As I mentioned earlier, I find Git
excellent for development (perhaps the best VCS there is), but too complex
for non-developers (and actually for many developers too). The latter is an
observable fact, not just an opinion. The reluctance to accept it is a bit
perplexing to me.

git "too hard to use"?

Posted Feb 28, 2010 20:25 UTC (Sun) by cmccabe (guest, #60281) [Link]

> I am sorry, but that it is nonsense. It is impossible to merge binary files
> like .DOC, .PDF, artwork, etc. Those ate precisely the type of documents
> that non-developers need. Branches are actively harmful to them.

It's impossible to merge them *automatically*. This is a flaw in the file format and toolset, and has nothing to do with version control per se.

If you have more than one documentation writer on the payroll, you're already spending time merging changes manually. Even if you make each chapter (or whatever) of documentation a separate file, there will still be some cross-references and dependencies.

If you would have used .tex and .svg, you wouldn't have this problem, or at least not to this extent. If you like Microsoft, their Sharepoint stuff is designed to solve exactly this problem-- to make office documents mergeable.

It's hard to see how you can get away from using subversion and mandatory locking with the workflow you have now. But this is not because employees are too stupid to understand branching. It's because the tools you are using are old and rusty, and don't support the diff operation. This also will make it hard for you to audit what people have done. If I make a few spelling corrections to the PDF and then commit it as "added whole new section on zebras" how is my manager going to know the difference? You're just using the honor system, basically.

By the way, if you need mandatory locking and good handling of binary files, you might also check out Perforce. They have good GUI and Windows support (although subversion has been improving a lot lately.)