[ANNOUNCE] yap: Yet Another (Git) Porcelain

[ANNOUNCE] yap: Yet Another (Git) Porcelain

[Steven Walter]

After starting yap several weeks ago, I feel it has reached a level of
maturity that makes it suitable for public consumption.  yap is three
things, in increasing order of relevance:

    1) A git porcelain implemented in python
    2) A git porcelain with a friendlier, more orthogonal interface
    3) A extensible git porcelain

The third point is most interesting, because as far as the author is
aware, it is the first such project to attempt to achieve this.
Included in this distribution are plugins to create backups during
revert, make "temporary" commits, and ease interoperability with
subversion repositories.

Using git to operate on subversion-hosted repositories is a frequent use
case, and will continue to be until the world embraces git as the
awesome tool it is (keep in mind that even CVS is still in common
usage).  The git-svn tool distributed with git greatly facilitates this.
However, using git-svn requires markedly different workflows, commands,
and mental processes than does working with git-native repositories.

By leveraging the extensible nature of yap, its svn mode strives to make
a remote svn repository act and feel as much like a git repository as
possible to lessen the impedance mismatch to the user.

Yap is still very much a work-in-progress.  Patches are welcome.
Suggestions are welcome.  Bug reports are expected.  Hopefully this
tool can fill a gap in your git toolbox.

Features
--------
    * Most commands are easily and clearly reversible (commit/uncommit).  Those
      that are not are clearly marked as such.
    * Commands that have potentially unintended side-effects warn about such.
      For example, "point" will warn if moving the branch would make some
      commits reachable only through the commit log
    * SVN interoperation
        * Cloning an SVN repository is no different than cloning a git
          repository (only slower)
        * Same command to push to an SVN repo as a git repo
        * Standard workflow (yap update) is appropriate for svn-based and
          git-native setups
        * Working with "cache repositories" is supported directly.  When
          cloning a repository generated by "yap clone <svn url>", the new
          repositories is automatically configured to push back to the
          subversion repository.
-- 
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818  7A65 FC81 9777 DC28 9E8F 

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

[Jakub Narebski]

Steven Walter <stevenrwalter@gmail.com> writes:

> After starting yap several weeks ago, I feel it has reached a level of
> maturity that makes it suitable for public consumption.  yap is three
> things, in increasing order of relevance:
> 
>     1) A git porcelain implemented in python
>     2) A git porcelain with a friendlier, more orthogonal interface
>     3) A extensible git porcelain

A question, and a request.

First, a question: how your yap porcelain differs from efforts of
EasyGit (eg) and Pyrite?

And a request: could you add (short) information about your work to
Git Wiki: http://git.or.cz/gitwiki/InterfacesFrontendsAndTools,
of course in the "Version Control Interface layers" section? 

TIA.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Giuseppe Bilotta]

On Saturday 06 September 2008 17:07, Steven Walter wrote:

> After starting yap several weeks ago

If you're interested in cross-platformness, you might want to be
aware that there is already at least another 'yap' in Windows:
MikTeX's DVI viewer (Yet Another Previewer). Just FYI.

> By leveraging the extensible nature of yap, its svn mode strives to make
> a remote svn repository act and feel as much like a git repository as
> possible to lessen the impedance mismatch to the user.

>     * SVN interoperation
>         * Cloning an SVN repository is no different than cloning a git
>           repository (only slower)
>         * Same command to push to an SVN repo as a git repo
>         * Standard workflow (yap update) is appropriate for svn-based and
>           git-native setups
>         * Working with "cache repositories" is supported directly.  When
>           cloning a repository generated by "yap clone <svn url>", the new
>           repositories is automatically configured to push back to the
>           subversion repository.

This is an extremely interesting idea. I've always wondered myself
if it were possible to make git-svn operation more transparent,
although it has always been my understanding that the interface
difference might be substantially driven by robustness, especially
for 'roundtrip' operation, and by the fact that svn would not
really be suited for some of the operations that are common in git
workflow. It'll be interesting to see the level of transparency
that can be achieved without bringing down the svn server ;)

I think that the most complex situations arise from cloning svn
repositories that undergo heavy structure changes in their
history, moving from a structure where there was no
trunk/branches/tags because the project was just kept in the svn
root, to thetraditional trunk/branches/tags structure (I've come
across at least two svn repositories like this in the past, and
git-svn used to have quite some problems in importing them
directely, although I haven't tried it recently).

-- 
Giuseppe "Oblomov" Bilotta

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

[Jeff King]

On Sat, Sep 06, 2008 at 11:07:23AM -0400, Steven Walter wrote:

> After starting yap several weeks ago, I feel it has reached a level of
> maturity that makes it suitable for public consumption.  yap is three

Link?

-Peff

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

[Steven Walter]

On Sat, Sep 6, 2008 at 1:39 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Sep 06, 2008 at 11:07:23AM -0400, Steven Walter wrote:
>> After starting yap several weeks ago, I feel it has reached a level of
>> maturity that makes it suitable for public consumption.  yap is three
>
> Link?

Heh, that would help.

http://repo.or.cz/w/yap.git
-- 
-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

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

[Jeff King]

On Sat, Sep 06, 2008 at 02:33:21PM -0400, Steven Walter wrote:

> http://repo.or.cz/w/yap.git

Hmm. Bug, or am I missing something fundamental?

  $ mkdir repo && cd repo
  $ yap init
  Initialized empty Git repository in /home/peff/repo/.git/
  $ echo content >file
  $ yap add file
  Current branch: master
  Files with staged changes:
          (none)
  Files with unstaged changes:
          file
  $ yap add file
  Current branch: master
  Files with staged changes:
          (none)
  Files with unstaged changes:
          file
          file
  $ yap add file
  Current branch: master
  Files with staged changes:
          (none)
  Files with unstaged changes:
          file
          file
          file

-Peff

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

[Steven Walter]

On Sat, Sep 6, 2008 at 2:40 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Sep 06, 2008 at 02:33:21PM -0400, Steven Walter wrote:
>
>> http://repo.or.cz/w/yap.git
>
> Hmm. Bug, or am I missing something fundamental?

Nope, simple bug.  Everything should still work correctly, but the
output was a bit confusing.  I just pushed a fix.
-- 
-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

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

[Jakub Narebski]

[Back on git mailing list]

On Sat, 6 Sep 2008, Steven Walter wrote:
> On Sat, Sep 6, 2008 at 11:36 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > First, a question: how your yap porcelain differs from efforts of
> > EasyGit (eg) and Pyrite?
> 
> In the case of EasyGit, it differs in that yap's interface does not
> have the requirement of being fully backwards-compatible with core
> git.  Dropping that requirement gave me more freedom to simplify and
> clean-up the interface.

I can understand this.  EasyGit is more about making git self
documenting than anything more, from what I understand.

> To my knowledge, Pyrite does not support plugins.

As far as I know Pyrite is one-man work.  Why not to join efforts,
bringing those two projects together?  Both share the same language,
Python.

> > And a request: could you add (short) information about your work to
> > Git Wiki: http://git.or.cz/gitwiki/InterfacesFrontendsAndTools,
> > of course in the "Version Control Interface layers" section?
> 
> Done.

Thanks.


By the way, please take into account 
  http://en.wikipedia.org/wiki/Yap_(disambiguation)

Most commonly known YAP is I think Yet Another Previewer, which is
the name of the DVI viewer included on the widely used MiKTeX TeX
distribution for the Microsoft Windows platform,

YAGP, or YA(G)P, is I think free of such conotations.
-- 
Jakub Narebski
Poland

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

[Steven Walter]

On Sat, Sep 6, 2008 at 3:01 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> To my knowledge, Pyrite does not support plugins.
>
> As far as I know Pyrite is one-man work.  Why not to join efforts,
> bringing those two projects together?  Both share the same language,
> Python.

That's an interesting idea and something I'd like to pursue.

> By the way, please take into account
>  http://en.wikipedia.org/wiki/Yap_(disambiguation)
>
> Most commonly known YAP is I think Yet Another Previewer, which is
> the name of the DVI viewer included on the widely used MiKTeX TeX
> distribution for the Microsoft Windows platform,
>
> YAGP, or YA(G)P, is I think free of such conotations.

I was not aware of that.  I'm not firmly attached to the name I've
chosen, but I would like the command to remain short (2-3 letters).
Maybe call it YAGP and use "yg" for the command?
-- 
-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

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

[Govind Salinas]

On Sat, Sep 6, 2008 at 2:01 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> [Back on git mailing list]
>
> On Sat, 6 Sep 2008, Steven Walter wrote:
>> On Sat, Sep 6, 2008 at 11:36 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> >
>> > First, a question: how your yap porcelain differs from efforts of
>> > EasyGit (eg) and Pyrite?
>>
>> In the case of EasyGit, it differs in that yap's interface does not
>> have the requirement of being fully backwards-compatible with core
>> git.  Dropping that requirement gave me more freedom to simplify and
>> clean-up the interface.
>
> I can understand this.  EasyGit is more about making git self
> documenting than anything more, from what I understand.
>
>> 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.

> As far as I know Pyrite is one-man work.  Why not to join efforts,
> bringing those two projects together?  Both share the same language,
> Python.
>

Sadly, yes.  It is still just me.  I would welcome any help or additions.
I don't have as much time as I would like to work on it.  But as it stands I
have a web interface (no push/pull yet, I am waiting for the git http
push/pull to be done to make sure I have compatibility.

If you want to look at it, you can find it here...

http://gitorious.org/projects/pyrite


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?

Good Luck.
Govind.

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

[Steven Walter]

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

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

[Govind Salinas]

On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter <stevenrwalter@gmail.com> wrote:
> 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?
>

Yes, but this is where it gets crude.  There are several things that happen.

You get an on_load() call that happens when the extension is loaded.  You
can use that to add a command.  You also get  an on_before_command()
and on_after_command() that get called when you might expect, you can
use this to do anything from alter command line parameter to post-
processing etc.  After that you have to hook methods, python makes this
pretty easy.  There is a known hook point by convention in every command,
after that you have to know what you want to hook in the particular command.

> 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.
>

You should be able to use the plugin system I have to hook the clone
command and run something different in the event that you have a svn
URL.  You would probably do this on_before_command.  This was
actually something someone brought up in a pyrite thread a while
back.  That should not be complicated.

> 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).

I had some very different ideas along the lines of reducing the number of
commands (where the commands do something similar just DWIM rather
than force me to remember or read docs on different commands), making
commands look similar to commands from other SCMs (revert should do
what it does for me in all the other SCMs that I have used, which is to
checkout the HEAD copy into the working directory) and improve
usability (WTF does ".." mean vs "..." and why is it different for different
commands, etc).  Perhaps we can talk and see if there is enough room for
both our goals.

A further goal of mine is to eventually help with the libgit project so that git
operations can be done from inside they python process rather than a
fork and exec.  This is an optimization, but it can also be used to get rid
of any scripting that remains in git, making it possible to have git on
windows without MSYS or cygwin.  Pyrite is very ambitious, as you might
tell from how long it has been taking me to do it.

-Govind