git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bryan Larsen <bryan.larsen@gmail.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: git, porcelain, darcs, and version 1.0
Date: Mon, 18 Jul 2005 16:18:54 -0400	[thread overview]
Message-ID: <42DC0EAE.8000600@gmail.com> (raw)
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

  reply	other threads:[~2005-07-18 20:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-16 20:45 Darcs-Git: upgrading to Git 0.99 Juliusz Chroboczek
2005-07-17 10:40 ` [darcs-devel] " David Roundy
2005-07-18  4:46 ` git, porcelain, darcs, and version 1.0 Bryan Larsen
2005-07-18 19:11   ` Junio C Hamano
2005-07-18 20:18     ` Bryan Larsen [this message]
2005-07-18 19:49   ` Juliusz Chroboczek
2005-07-18 20:28     ` Bryan Larsen

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=42DC0EAE.8000600@gmail.com \
    --to=bryan.larsen@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /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;
as well as URLs for NNTP newsgroup(s).