From: Bryan Larsen <bryan.larsen@gmail.com>
Date: Mon, 18 Jul 2005 20:18:54 GMT
Subject: Re: git, porcelain, darcs, and version 1.0
Message-ID: <42DC0EAE.8000600@gmail.com>
In-Reply-To: <7vslycnd42.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:
> 
> I fully agree that supporting C-level linkage is worthy, and
> should be one of our longer term goals.

Excellent.
> 
> 
>>A similar 1.0 goal would be to document porcelain's use of the .git
>>directory.  For instance, stacked git uses .git/patches,
>>.git/patchdescr.tmpl and .git/patchexport.tmpl.  If Linus does not
>>accept a patch documenting this usage, stacked git should use .stgit
>>instead.
> 
> 
> I agree that coordinating the namespace under $GIT_DIR among
> Porcelains is something we need (it was what prompted me to
> steal the branches/ convention from Cogito).  The job of the
> core should be to help Porcelains avoid stepping on each other's
> toes.
> 
> The documentation of the internals for $GIT_DIR/patches is
> probably better left to StGIT documentation, though, at the
> moment.  When other Porcelains start wishing to access the
> "series of patches expressed as a set of commit chain" expressed
> by StGIT there (e.g. show patch series in addition to regular
> commit chain in gitk), the core should help the Porcelains to
> work well with each other, to do things in a compatible way.
> This may involve moving some common things to core side and
> mention the convention for Porcelains to work well together in
> the core documentation.

I think we want the same thing, you're just expressing it explicitly: 
stgit's usage of the .git namespace should be mentioned in git 
documentation.  actual details belong in stgit, either explicitly in 
documentation or implicitly in the code.


> 
> However, I am slightly negative about suggesting these two to be
> part of the 1.0 goals.  Linus wanted to make 1.0 how many weeks
> ago?  I personally think that a usable baseline, stable enough
> to allow stripping out the core part currently shipped as part
> of Cogito, would be a good place to stop and declare 1.0.  My
> list was meant to enumuerate what might be missing from the
> "usable baseline".

All I'm looking for is a statement like "once we're at 1.0, darcs 
doesn't break until 2.0".  If we don't actually break out a blessed lib 
interface until 1.1,  that's fine with me.  To me, 1.0 implies core 
stability.

thanks,
Bryan