From: Michael J Gruber <git@drmicha.warpmail.net>
To: David Lang <david@lang.hm>, Shawn Pearce <spearce@spearce.org>
Cc: Stefan Beller <sbeller@google.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: An interesting opinion on DVCS/git
Date: Wed, 04 Mar 2015 16:25:07 +0100 [thread overview]
Message-ID: <54F723D3.1050805@drmicha.warpmail.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1503031642340.26501@nftneq.ynat.uz>
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
next prev parent reply other threads:[~2015-03-04 15:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54F2CD12.8050609@gmail.com>
2015-03-02 3:29 ` Fwd: An interesting opinion on DVCS/git Stefan Beller
2015-03-03 22:49 ` Shawn Pearce
2015-03-03 23:24 ` Junio C Hamano
2015-03-03 23:55 ` Randall S. Becker
2015-03-04 0:53 ` David Lang
2015-03-04 15:25 ` Michael J Gruber [this message]
2015-03-06 3:25 ` Sitaram Chamarty
2015-03-09 14:47 ` Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F723D3.1050805@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=david@lang.hm \
--cc=git@vger.kernel.org \
--cc=sbeller@google.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).