Junio C Hamano wrote:

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


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

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

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.

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

Reply via email to