All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Sorenson <frank@tuxrocks.com>
To: Junio C Hamano <junkio@cox.net>
Cc: Catalin Marinas <catalin.marinas@gmail.com>,
	Bryan Larsen <bryan.larsen@gmail.com>,
	git@vger.kernel.org
Subject: Re: Barebone Porcelain.  Where to stop?
Date: Mon, 18 Jul 2005 14:57:41 -0600	[thread overview]
Message-ID: <42DC17C5.80000@tuxrocks.com> (raw)
In-Reply-To: <7v8y04q6sj.fsf@assigned-by-dhcp.cox.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junio C Hamano wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
> 
>>I don't see git going towards stgit at all. Indeed, it gets closer to
>>cogito but I still like cogito over plain git since it's easier to use
>>(my goal, though, is to add pull/clone commands to stgit so that one
>>doesn't need to rely on directly using other tools).
> 
> All good to hear.  I do not speak for Linus, but I think core
> should not be competing with Porcelain.  To me, there are four
> purposes for the barebone Porcelain layer:
> 
>  (1) provide the end user a minimum UI to do essential things.
> 
>  (2) codify the BCP/convention to use the core by higher level
>      SCMs to help them stay compatible with each other where
>      possible (e.g. "what .git/HEAD means, when it gets updated,
>      and to what" was discussed recently).
> 
>  (3) serve as an example for people interested in learning the
>      core GIT (i.e. they may be starting their own Porcelain).
> 
>  (4) implement operations that are heavy on logic/convention but
>      does not have much UI need so that higher level SCMs can
>      implement their own UI by just being a thin wrapper around
>      them (e.g. clone/fetch and push).

These all sound good.  Along the lines of #4, one potential purpose I've
been curious about is the possibility of pulling these core operations
out into a library that Porcelain could use directly.  This way,
Porcelain, including the minimum git UI (your #1), could directly link
in and call the needed functions, and rather than stringing sequences of
git-whatever commands together in a shell script.

This would allow Porcelain to take advantage of the core git more
directly, and would improve the speed of Porcelain.  The minimum UI (#1)
would be a much simpler example (#3), since it would only be the
front-end, rather than the front-end/back-end combination it is now.

Is this something we want to consider, or am I out in left field? :)

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC3BfFaI0dwg4A47wRApyQAKD3yXqYfcm7TgJ5GnIZsw5ZcB+P/wCgpM75
cjPHXi8jd0VthQjKNFITFxU=
=Jxx/
-----END PGP SIGNATURE-----

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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-16 17:37 Barebone Porcelain. Where to stop? Junio C Hamano
2005-07-18  4:41 ` Bryan Larsen
2005-07-18 10:22   ` Catalin Marinas
2005-07-18 18:59     ` Junio C Hamano
2005-07-18 20:57       ` Frank Sorenson [this message]
2005-07-19  0:10         ` Junio C Hamano

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=42DC17C5.80000@tuxrocks.com \
    --to=frank@tuxrocks.com \
    --cc=bryan.larsen@gmail.com \
    --cc=catalin.marinas@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.