On Tue, 3 Mar 2015, Shawn Pearce wrote:

On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbel...@google.com> wrote:
bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity

Indeed, a DVCS like Git or Hg does not fit everyone. And neither do
centralized systems like Subversion. Choice is good.

However... I found some passages troubling for Git, e.g.:

---snip---
Git is so amazingly simple to use that APress, a single publisher,
needs to have three different books on how to use it. It’s so simple
that Atlassian and GitHub both felt a need to write their own online
tutorials to try to clarify the main Git tutorial on the actual Git
website. It’s so transparent that developers routinely tell me that
the easiest way to learn Git is to start with its file formats and
work up to the commands.
---snap---

We have heard this sort of feedback for years. But we have been unable
to adequately write our own documentation or clean up our man pages to
be useful to the average person who doesn't know why the --no-frobbing
option doesn't disable the --frobinator option to the
--frobbing-subcommand of git frob.  :(

http://git-man-page-generator.lokaltog.net/ shouldn't exist and
shouldn't be funny. Yet it does. :(

As for the different online tutorials, I'll point out that every university that supports it's students using Thunderbird has it's own version of a tutorial on how to use and configure Thunderbird. The question is if they are coverying their one use case of how to use git with their service, or if they are trying to duplicate the git documentation.


There are two reasons for having multiple books out for a piece of software

1. the software is horribly complicated to use, even for beginners

2. the software is extremely powerful, to to understand all the different advanced options, and when to use them, takes a lot of explination

In the case of git, there's a bit of both.

Part of the problem is that there are so many different ways to use it (all in common use) that there isn't one simple set of insructions that will be right in all the different use cases (thus the value of services that force users to operate in one specific model providing a tutorial in how to use it with their service)

At this point, Internet Lore says "git is hard to use", and if you approach any software with that attitude, you will find lots of things to point at to justify your opinion.

I'm not saying that there isn't room for improvement, I'm just saying that the evidence provided is not as one-sided as they make it sound.

David Lang

Reply via email to