Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain

["Steven Walter" <stevenrwalter@gmail.com>]

On Sun, Sep 7, 2008 at 11:45 PM, Govind Salinas
<govind@sophiasuchtig.com> wrote:
>>> To my knowledge, Pyrite does not support plugins.
>
> Depends on what you mean by plugins.  There is a way to load what I call
> extensions that you can use to add commands or modify the way existing
> commands operate.  It is crude at the moment but it works.  I have a
> proof of concept extension/plugin that adds different ways of specifying
> revisions.  I assume you mean something similar.

That pretty well describes what I mean by a plugin system.  Does your
system allow anything other than commands to be overridden?  Do your
commands ever call other commands, and if so, will the overridden
method be called in that case?

Yap's plugin system is pretty nice (IMHO), but it was designed almost
exclusively as a means to an end: the svn plugin.  With the svn
plugin, "yap clone" will accept an SVN url as readily as a git URL,
and the result it what you would expect if you had a git URL:  a
full-history git clone of the svn repository with all branches and
tags.  Obviously, the svn clone would be much slower than the
equivalent git command, but that's the price one pays in interacting
with svn.  However, this "yap" repo can then be cloned, and all the
svn meta-information will be present in the new repository.  This
means that the new repository can immediately be used for pushing
commits back to the original svn repository without any additional
configuration.  Additionally, you can use an svn revision anywhere a
git committish can be used.

In a yap "yap-svn" clone, "svn" appears as just another remote.  "yap
push svn foo" does the expected thing.  Likewise for fetching and
updating.  In theory a similarly parallel interface could be provided
to other SCMs.  Facilitating users who track SVN repositories with git
was one of the majors goals of the yap project, and I encourage users
who do so to give yap a try.

> I am currently not doing much work on the command line interface since
> people seemed to object to my ideas.  Instead I am focusing on the gui
> instead.  Since you say you are not going to keep the command lines
> compatible, what do you intend to do differently?

The command-line interface has been my primary focus, as that is what
I and my co-workers usually use.  The interface that yap has now is
intended to be more orthogonal and "safer" than the standard git
porcelain.  By "safer" I mean that yap will not perform an operation
that cannot be readily reversed without explicit confirmation (an "-f"
flag, for instance).  For example, the closest equivalent to "git
reset --hard" in yap is "yap point."  yap point fails if there are any
uncommitted changes (staged or unstaged), or if it would create
"dangling commits" that can no longer be referenced by a ref (unless
"-f" is given).  On the orthogonal side, "yap" provides
commit/uncommit as a pair, as well as stage/unstage.  They are small
things, but small things can make a big improvement in user experience
(especially if it keeps you from killing uncommitted changes you had
forgotten about).
-- 
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
 -Robert Heinlein