Re: as promised, docs: git for the confused

From: linux@horizon.com <linux@horizon.com>
Date: Dec 9, 2005, 21:54 UTC
Message-ID: <20051209215414.14072.qmail@science.horizon.com>
In-Reply-To: <7vzmna2ig2.fsf@assigned-by-dhcp.cox.net>

Show 5 quoted lines

> This primarily comes from the way git is architected.  We have
> many commands that are not so interesting from the end-user
> perspective.  If git were architected differently, many of them
> may not exist in executable command form, but would instead be
> library functions and listed in section 3git of the manual.

But you also have commands of interest or not to different classes of users.

Some users want to track someone else's repository. Others want to generate their repository from scratch. Or maybe import some history from CVS.

Some users spend all day applying patches. Some spend all day creating patches. Some just want to retrieve the kernel and run "git bisect" to help the kernel developers. They will neither generate nor apply patches. Some want access to a developer's git repository to test bleeding-edge drivers.

Some folks want to set up remote access to a shared repository within a development group. Some folks want to set up an anonymous git server.

Et cetera. There are many different constituencies, who will want access to a different subset of the commands.

Show 6 quoted lines

> Exactly.  The tutorial can also use a minor split.  It starts
> out to give taste of internal workins of Porcelains, but ends up
> being a fuzzy mix of "user manual" and "hints to porcelain
> writers".  We probably should have a separate "end user
> tutorial" --- the Alice-Bob scenario by Horst might be a good
> place to start.

That much, I definitely agree with.  Mixing the two is confusing.