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
next prev parent 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 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.