From: Petr Baudis <pasky@suse.cz>
To: Sean <seanlkml@sympatico.ca>
Cc: Git Mailing List <git@vger.kernel.org>,
A Large Angry SCM <gitzilla@gmail.com>,
Rene Scharfe <rene.scharfe@lsrfire.ath.cx>,
Junio C Hamano <junkio@cox.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH] Document git-runstatus
Date: Sun, 19 Nov 2006 19:13:08 +0100 [thread overview]
Message-ID: <20061119181307.GY7201@pasky.or.cz> (raw)
In-Reply-To: <20061118150431.81076072.seanlkml@sympatico.ca>
On Sat, Nov 18, 2006 at 09:04:31PM CET, Sean wrote:
> On Sat, 18 Nov 2006 11:37:14 -0800
> A Large Angry SCM <gitzilla@gmail.com> wrote:
>
> > I disagree. If a command is install on a system, it's man
> > pages/documentation should also be installed.
>
> Well this isn't a huge issue. One point you made though that struck
> a chord is that many of the commands should probably not be in
> section 1.
The trouble is that there's no other good place where to put them. But
perhaps we can get away with putting them to section 3? After all, Perl
installs documentation for its modules to section 3 as well.
> > I'm also not convinced that there are a "large number of commands [...]
> > that should only ever be accessed as plumbing". I am convinced, however,
> > that there are a number of relatively low level commands with poor user
> > interfaces that are useful on their own.
>
> Is there really a reason for a git user to access these from the
> command line rather than a script:
>
> commit-tree, diff-files, diff-index, diff-tree, for-each-ref,
> hash-object, http-fetch, http-push, index-pack, local-fetch,
> merge-base, merge-index, merge-octopus, merge-one-file, merge-ours,
> merge-recur, merge-recursive, merge-recursive-old, merge-resolve,
> merge-stupid, merge-tree, receive-pack, runstatus, ssh-fetch, ssh-pull,
> ssh-push, ssh-upload, symbolic-ref, unpack-file, unpack-objects,
> update-ref, upload-archive, upload-pack, upload-tar, write-tree
>
> Not a complete list, and maybe i overlooked something in there
> that is needed from the command line, but for the most part
> these could be installed somewhere other than the users path.
There certainly are reasons, but the situations where it is needed is
sufficiently rare; I think that's a reason good enough, when doing
something exotic like recovery of a corrupted repository it's ok to have
to do something slightly special to execute a lowlevel command.
It has been proposed for a long time that we put the "pure plumbing"
commands to /usr/libexec/git/ or somewhere there (some say /usr/libexec/
is obsolete), and I think it would be a great move. Note that nowadays
the transition needs to be done carefully because of backwards
compatibility.
BTW, I've finally found a fine example of situation parallel to Git:
TeX! There are the core TeX commands (plumbing) and plain TeX (basic
porcelain) on top of that as well as a bunch of other macro sets (other
porcelains). Now I need to dig out The TeXbook from wherever I've put it
to see how did Knuth deal with it, documentation-wise.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
next prev parent reply other threads:[~2006-11-19 18:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-18 14:15 [PATCH] Document git-runstatus Rene Scharfe
2006-11-18 14:26 ` Sean
[not found] ` <20061118092644.a9f15669.seanlkml@sympatico.ca>
2006-11-18 14:35 ` Petr Baudis
2006-11-18 15:04 ` Rene Scharfe
2006-11-18 16:04 ` Sean
2006-11-18 18:20 ` A Large Angry SCM
2006-11-18 18:49 ` Sean
[not found] ` <455F60EA.2080009@gmail.com>
2006-11-18 20:04 ` Sean
[not found] ` <20061118150431.81076072.seanlkml@sympatico.ca>
2006-11-19 18:13 ` Petr Baudis [this message]
2006-11-20 7:15 ` Joshua N Pritikin
2006-11-20 8:11 ` Jakub Narebski
2006-11-18 18:49 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061119181307.GY7201@pasky.or.cz \
--to=pasky@suse.cz \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitzilla@gmail.com \
--cc=junkio@cox.net \
--cc=peff@peff.net \
--cc=rene.scharfe@lsrfire.ath.cx \
--cc=seanlkml@sympatico.ca \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox