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