Re: An interesting opinion on DVCS/git

[Michael J Gruber <git@drmicha.warpmail.net>]

David Lang venit, vidit, dixit 04.03.2015 01:53:
> On Tue, 3 Mar 2015, Shawn Pearce wrote:
> 
>> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@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
> 

Yes, that article has a few really weak lines of arguments, such as the
tutorial count.

Also, that advice to "learn git from the file formats", which I hope
means something like "learn the structure, not recipes" is good advice
for learning any powerful toolset - rediculing it is not quite a proof
of intelligence.

And I don't think there's anything we have to regret about the basic
architecture of (the DAG/object structure of) git. (OK, the various
signature formats ;)

That being said, we all know how often we want to change the UI and
backwards compatibility keeps us from doing so. The UI could really
benefit from a fresh start, where, based on what we know now, we first
think about:

- How do we structure/denote subcommands within commands? E.g. to dash
or not to dash, default subcommand etc.

- How do we structure "read" commands vs. "write" commands? E.g. the
pairs "branch [-l]"/"branch <name>", "log"/"commit" etc.

- How do we name options consistently? E.g. -n=--dry-run everywhere

- How do we make working with the special git concepts more natural?
E.g. index, detached heads.

Michael