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@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html