From: Kevin Smith <yarcs@qualitycode.com>
To: Klaus Robert Suetterlin <robert@mpe.mpg.de>
Cc: git@vger.kernel.org
Subject: Re: missing: git api, reference, user manual and mission statement
Date: Tue, 19 Apr 2005 09:51:56 -0400 [thread overview]
Message-ID: <42650CFC.1010400@qualitycode.com> (raw)
In-Reply-To: <20050419123631.GD3739@xdt04.mpe-garching.mpg.de>
Klaus Robert Suetterlin wrote:
> 1) There is no clear (e.g. by name) distinction between ``git as done
> by Linus'', which is a kind of content addressable database with added
> semantics, and ``git as done by the rest of You'', which is a kind of
> SCM on top of Linuses stuff.
I also see this as one of the biggest obstacles right now. It would be
very helpful if we could achieve the clear separation between git and
non-git that has been part of the design since the beginning.
Git is very immature, and currently should only be used by brave
pioneers. About the only way for a mortal to even try git is to stick to
git-pasky releases, and not try to track all the patches flying around.
> Linus must have had an idea of the final product, and how to use
> that. The real day to day workflow.
The best description I have seen so far is the README for git-pasky:
http://pasky.or.cz/~pasky/dev/git/
It's not a bad mini-tutorial, really.
> I really believe a lot of questions on the git mailing list could
> be answered if there was a user manual and a reference for git.
> Even before all of it will be implemented.
As you know, documentation is a great way for non-coders to contribute
to a project. Until someone steps up to write it, it won't happen.
In a highly iterative development process like this one, it actually
doesn't make sense to write the docs first. You really don't know how it
should work until you code it, play with it, and then realize it should
be doing something different.
> The list of dependencies is long and growing. So if the intent of
> doing gitSCM with shell scripts was to make it portable: that goal was missed.
I think the main goal was rapid implementation. I totally expect there
to be one or several wrappers, written in various languages, that will
eventually replace git-pasky.
> Still gitLinus lacks a clear definition of its interface, so I
> guess no one will be able to tell if it works correct. How could You
> do a test case without knowing
> a) what the software should do and
> b) how You should tell it?
I agree that it would be nice to have automated unit tests.
> And of course there are still memory leaks.
The code is still young, and these will be fixed. I'm not bothered that
there are leaks at this moment. I am a bit bothered by Linus's attitude
that some small leaks might not ever need to be fixed.
Kevin
next prev parent reply other threads:[~2005-04-19 13:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 12:36 missing: git api, reference, user manual and mission statement Klaus Robert Suetterlin
2005-04-19 13:51 ` Kevin Smith [this message]
2005-04-19 13:58 ` Ingo Molnar
2005-04-19 14:10 ` Kevin Smith
2005-04-19 16:58 ` Petr Baudis
2005-04-20 17:15 ` Andrew Timberlake-Newell
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=42650CFC.1010400@qualitycode.com \
--to=yarcs@qualitycode.com \
--cc=git@vger.kernel.org \
--cc=robert@mpe.mpg.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.