{"thread":{"id":"15395","subject":"[ANNOUNCE] yap: Yet Another (Git) Porcelain","startedAt":"2008-09-06T15:07:23Z","lastAt":"2008-09-09T04:25:00Z","messageCount":12,"participants":["Steven Walter","Jakub Narebski","Giuseppe Bilotta","Jeff King","Govind Salinas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"89906","messageId":"20080906150723.GA31540@dervierte","threadId":"15395","inReplyTo":null,"subject":"[ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-06T15:07:23Z","receivedAt":"2008-09-06T15:07:23Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"After starting yap several weeks ago, I feel it has reached a level of\nmaturity that makes it suitable for public consumption. yap is three\nthings, in increasing order of relevance:\n\n 1) A git porcelain implemented in python\n 2) A git porcelain with a friendlier, more orthogonal interface\n 3) A extensible git porcelain\n\nThe third point is most interesting, because as far as the author is\naware, it is the first such project to attempt to achieve this.\nIncluded in this distribution are plugins to create backups during\nrevert, make \"temporary\" commits, and ease interoperability with\nsubversion repositories.\n\nUsing git to operate on subversion-hosted repositories is a frequent use\ncase, and will continue to be until the world embraces git as the\nawesome tool it is (keep in mind that even CVS is still in common\nusage). The git-svn tool distributed with git greatly facilitates this.\nHowever, using git-svn requires markedly different workflows, commands,\nand mental processes than does working with git-native repositories.\n\nBy leveraging the extensible nature of yap, its svn mode strives to make\na remote svn repository act and feel as much like a git repository as\npossible to lessen the impedance mismatch to the user.\n\nYap is still very much a work-in-progress. Patches are welcome.\nSuggestions are welcome. Bug reports are expected. Hopefully this\ntool can fill a gap in your git toolbox.\n\nFeatures\n--------\n * Most commands are easily and clearly reversible (commit/uncommit). Those\n that are not are clearly marked as such.\n * Commands that have potentially unintended side-effects warn about such.\n For example, \"point\" will warn if moving the branch would make some\n commits reachable only through the commit log\n * SVN interoperation\n * Cloning an SVN repository is no different than cloning a git\n repository (only slower)\n * Same command to push to an SVN repo as a git repo\n * Standard workflow (yap update) is appropriate for svn-based and\n git-native setups\n * Working with \"cache repositories\" is supported directly. When\n cloning a repository generated by \"yap clone \", the new\n repositories is automatically configured to push back to the\n subversion repository.\n-- \n-Steven Walter \nFreedom is the freedom to say that 2 + 2 = 4\nB2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F \n"},{"id":"89908","messageId":"m38wu5p9q4.fsf@localhost.localdomain","threadId":"15395","inReplyTo":"20080906150723.GA31540@dervierte","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-06T15:36:40Z","receivedAt":"2008-09-06T15:36:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Steven Walter writes:\n\n> After starting yap several weeks ago, I feel it has reached a level of\n> maturity that makes it suitable for public consumption. yap is three\n> things, in increasing order of relevance:\n> \n> 1) A git porcelain implemented in python\n> 2) A git porcelain with a friendlier, more orthogonal interface\n> 3) A extensible git porcelain\n\nA question, and a request.\n\nFirst, a question: how your yap porcelain differs from efforts of\nEasyGit (eg) and Pyrite?\n\nAnd a request: could you add (short) information about your work to\nGit Wiki: http://git.or.cz/gitwiki/InterfacesFrontendsAndTools,\nof course in the \"Version Control Interface layers\" section? \n\nTIA.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"89912","messageId":"g9ubn8$deg$1@ger.gmane.org","threadId":"15395","inReplyTo":"20080906150723.GA31540@dervierte","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2008-09-06T16:39:02Z","receivedAt":"2008-09-06T16:39:02Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Saturday 06 September 2008 17:07, Steven Walter wrote:\n\n> After starting yap several weeks ago\n\nIf you're interested in cross-platformness, you might want to be\naware that there is already at least another 'yap' in Windows:\nMikTeX's DVI viewer (Yet Another Previewer). Just FYI.\n\n> By leveraging the extensible nature of yap, its svn mode strives to make\n> a remote svn repository act and feel as much like a git repository as\n> possible to lessen the impedance mismatch to the user.\n\n> * SVN interoperation\n> * Cloning an SVN repository is no different than cloning a git\n> repository (only slower)\n> * Same command to push to an SVN repo as a git repo\n> * Standard workflow (yap update) is appropriate for svn-based and\n> git-native setups\n> * Working with \"cache repositories\" is supported directly. When\n> cloning a repository generated by \"yap clone \", the new\n> repositories is automatically configured to push back to the\n> subversion repository.\n\nThis is an extremely interesting idea. I've always wondered myself\nif it were possible to make git-svn operation more transparent,\nalthough it has always been my understanding that the interface\ndifference might be substantially driven by robustness, especially\nfor 'roundtrip' operation, and by the fact that svn would not\nreally be suited for some of the operations that are common in git\nworkflow. It'll be interesting to see the level of transparency\nthat can be achieved without bringing down the svn server ;)\n\nI think that the most complex situations arise from cloning svn\nrepositories that undergo heavy structure changes in their\nhistory, moving from a structure where there was no\ntrunk/branches/tags because the project was just kept in the svn\nroot, to thetraditional trunk/branches/tags structure (I've come\nacross at least two svn repositories like this in the past, and\ngit-svn used to have quite some problems in importing them\ndirectely, although I haven't tried it recently).\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"89914","messageId":"20080906173925.GA4044@coredump.intra.peff.net","threadId":"15395","inReplyTo":"20080906150723.GA31540@dervierte","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-06T17:39:25Z","receivedAt":"2008-09-06T17:39:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 06, 2008 at 11:07:23AM -0400, Steven Walter wrote:\n\n> After starting yap several weeks ago, I feel it has reached a level of\n> maturity that makes it suitable for public consumption. yap is three\n\nLink?\n\n-Peff\n"},{"id":"89921","messageId":"e06498070809061133p2e3a206fmfd47961645b15ff@mail.gmail.com","threadId":"15395","inReplyTo":"20080906173925.GA4044@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-06T18:33:21Z","receivedAt":"2008-09-06T18:33:21Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Sat, Sep 6, 2008 at 1:39 PM, Jeff King wrote:\n> On Sat, Sep 06, 2008 at 11:07:23AM -0400, Steven Walter wrote:\n>> After starting yap several weeks ago, I feel it has reached a level of\n>> maturity that makes it suitable for public consumption. yap is three\n>\n> Link?\n\nHeh, that would help.\n\nhttp://repo.or.cz/w/yap.git\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"89922","messageId":"20080906184033.GA4598@coredump.intra.peff.net","threadId":"15395","inReplyTo":"e06498070809061133p2e3a206fmfd47961645b15ff@mail.gmail.com","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-06T18:40:33Z","receivedAt":"2008-09-06T18:40:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 06, 2008 at 02:33:21PM -0400, Steven Walter wrote:\n\n> http://repo.or.cz/w/yap.git\n\nHmm. Bug, or am I missing something fundamental?\n\n $ mkdir repo && cd repo\n $ yap init\n Initialized empty Git repository in /home/peff/repo/.git/\n $ echo content >file\n $ yap add file\n Current branch: master\n Files with staged changes:\n (none)\n Files with unstaged changes:\n file\n $ yap add file\n Current branch: master\n Files with staged changes:\n (none)\n Files with unstaged changes:\n file\n file\n $ yap add file\n Current branch: master\n Files with staged changes:\n (none)\n Files with unstaged changes:\n file\n file\n file\n\n-Peff\n"},{"id":"89923","messageId":"e06498070809061145j712a578bobb761fbbbc34c082@mail.gmail.com","threadId":"15395","inReplyTo":"20080906184033.GA4598@coredump.intra.peff.net","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-06T18:45:59Z","receivedAt":"2008-09-06T18:45:59Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Sat, Sep 6, 2008 at 2:40 PM, Jeff King wrote:\n> On Sat, Sep 06, 2008 at 02:33:21PM -0400, Steven Walter wrote:\n>\n>> http://repo.or.cz/w/yap.git\n>\n> Hmm. Bug, or am I missing something fundamental?\n\nNope, simple bug. Everything should still work correctly, but the\noutput was a bit confusing. I just pushed a fix.\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"89924","messageId":"200809062101.28672.jnareb@gmail.com","threadId":"15395","inReplyTo":"e06498070809060912q2f7ed0cflb02e3efc7b81976e@mail.gmail.com","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-06T19:01:26Z","receivedAt":"2008-09-06T19:01:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Back on git mailing list]\n\nOn Sat, 6 Sep 2008, Steven Walter wrote:\n> On Sat, Sep 6, 2008 at 11:36 AM, Jakub Narebski wrote:\n> >\n> > First, a question: how your yap porcelain differs from efforts of\n> > EasyGit (eg) and Pyrite?\n> \n> In the case of EasyGit, it differs in that yap's interface does not\n> have the requirement of being fully backwards-compatible with core\n> git. Dropping that requirement gave me more freedom to simplify and\n> clean-up the interface.\n\nI can understand this. EasyGit is more about making git self\ndocumenting than anything more, from what I understand.\n\n> To my knowledge, Pyrite does not support plugins.\n\nAs far as I know Pyrite is one-man work. Why not to join efforts,\nbringing those two projects together? Both share the same language,\nPython.\n\n> > And a request: could you add (short) information about your work to\n> > Git Wiki: http://git.or.cz/gitwiki/InterfacesFrontendsAndTools,\n> > of course in the \"Version Control Interface layers\" section?\n> \n> Done.\n\nThanks.\n\n\nBy the way, please take into account \n http://en.wikipedia.org/wiki/Yap_(disambiguation)\n\nMost commonly known YAP is I think Yet Another Previewer, which is\nthe name of the DVI viewer included on the widely used MiKTeX TeX\ndistribution for the Microsoft Windows platform,\n\nYAGP, or YA(G)P, is I think free of such conotations.\n-- \nJakub Narebski\nPoland\n"},{"id":"89928","messageId":"e06498070809061304v368faf66tf5e5a153212306a8@mail.gmail.com","threadId":"15395","inReplyTo":"200809062101.28672.jnareb@gmail.com","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-06T20:04:06Z","receivedAt":"2008-09-06T20:04:06Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Sat, Sep 6, 2008 at 3:01 PM, Jakub Narebski wrote:\n>> To my knowledge, Pyrite does not support plugins.\n>\n> As far as I know Pyrite is one-man work. Why not to join efforts,\n> bringing those two projects together? Both share the same language,\n> Python.\n\nThat's an interesting idea and something I'd like to pursue.\n\n> By the way, please take into account\n> http://en.wikipedia.org/wiki/Yap_(disambiguation)\n>\n> Most commonly known YAP is I think Yet Another Previewer, which is\n> the name of the DVI viewer included on the widely used MiKTeX TeX\n> distribution for the Microsoft Windows platform,\n>\n> YAGP, or YA(G)P, is I think free of such conotations.\n\nI was not aware of that. I'm not firmly attached to the name I've\nchosen, but I would like the command to remain short (2-3 letters).\nMaybe call it YAGP and use \"yg\" for the command?\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"90043","messageId":"5d46db230809072045u7ade2d62i514aac49149a463d@mail.gmail.com","threadId":"15395","inReplyTo":"200809062101.28672.jnareb@gmail.com","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Govind Salinas","fromEmail":"govind@sophiasuchtig.com","sentAt":"2008-09-08T03:45:30Z","receivedAt":"2008-09-08T03:45:30Z","isPatch":false,"sender":{"key":"govind@sophiasuchtig.com","avatar":null},"body":"On Sat, Sep 6, 2008 at 2:01 PM, Jakub Narebski wrote:\n> [Back on git mailing list]\n>\n> On Sat, 6 Sep 2008, Steven Walter wrote:\n>> On Sat, Sep 6, 2008 at 11:36 AM, Jakub Narebski wrote:\n>> >\n>> > First, a question: how your yap porcelain differs from efforts of\n>> > EasyGit (eg) and Pyrite?\n>>\n>> In the case of EasyGit, it differs in that yap's interface does not\n>> have the requirement of being fully backwards-compatible with core\n>> git. Dropping that requirement gave me more freedom to simplify and\n>> clean-up the interface.\n>\n> I can understand this. EasyGit is more about making git self\n> documenting than anything more, from what I understand.\n>\n>> To my knowledge, Pyrite does not support plugins.\n>\n\nDepends on what you mean by plugins. There is a way to load what I call\nextensions that you can use to add commands or modify the way existing\ncommands operate. It is crude at the moment but it works. I have a\nproof of concept extension/plugin that adds different ways of specifying\nrevisions. I assume you mean something similar.\n\n> As far as I know Pyrite is one-man work. Why not to join efforts,\n> bringing those two projects together? Both share the same language,\n> Python.\n>\n\nSadly, yes. It is still just me. I would welcome any help or additions.\nI don't have as much time as I would like to work on it. But as it stands I\nhave a web interface (no push/pull yet, I am waiting for the git http\npush/pull to be done to make sure I have compatibility.\n\nIf you want to look at it, you can find it here...\n\nhttp://gitorious.org/projects/pyrite\n\n\nI am currently not doing much work on the command line interface since\npeople seemed to object to my ideas. Instead I am focusing on the gui\ninstead. Since you say you are not going to keep the command lines\ncompatible, what do you intend to do differently?\n\nGood Luck.\nGovind.\n"},{"id":"90156","messageId":"e06498070809081805l46ff295du69d8c9a2cc0ef59a@mail.gmail.com","threadId":"15395","inReplyTo":"5d46db230809072045u7ade2d62i514aac49149a463d@mail.gmail.com","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2008-09-09T01:05:28Z","receivedAt":"2008-09-09T01:05:28Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Sun, Sep 7, 2008 at 11:45 PM, Govind Salinas\n wrote:\n>>> To my knowledge, Pyrite does not support plugins.\n>\n> Depends on what you mean by plugins. There is a way to load what I call\n> extensions that you can use to add commands or modify the way existing\n> commands operate. It is crude at the moment but it works. I have a\n> proof of concept extension/plugin that adds different ways of specifying\n> revisions. I assume you mean something similar.\n\nThat pretty well describes what I mean by a plugin system. Does your\nsystem allow anything other than commands to be overridden? Do your\ncommands ever call other commands, and if so, will the overridden\nmethod be called in that case?\n\nYap's plugin system is pretty nice (IMHO), but it was designed almost\nexclusively as a means to an end: the svn plugin. With the svn\nplugin, \"yap clone\" will accept an SVN url as readily as a git URL,\nand the result it what you would expect if you had a git URL: a\nfull-history git clone of the svn repository with all branches and\ntags. Obviously, the svn clone would be much slower than the\nequivalent git command, but that's the price one pays in interacting\nwith svn. However, this \"yap\" repo can then be cloned, and all the\nsvn meta-information will be present in the new repository. This\nmeans that the new repository can immediately be used for pushing\ncommits back to the original svn repository without any additional\nconfiguration. Additionally, you can use an svn revision anywhere a\ngit committish can be used.\n\nIn a yap \"yap-svn\" clone, \"svn\" appears as just another remote. \"yap\npush svn foo\" does the expected thing. Likewise for fetching and\nupdating. In theory a similarly parallel interface could be provided\nto other SCMs. Facilitating users who track SVN repositories with git\nwas one of the majors goals of the yap project, and I encourage users\nwho do so to give yap a try.\n\n> I am currently not doing much work on the command line interface since\n> people seemed to object to my ideas. Instead I am focusing on the gui\n> instead. Since you say you are not going to keep the command lines\n> compatible, what do you intend to do differently?\n\nThe command-line interface has been my primary focus, as that is what\nI and my co-workers usually use. The interface that yap has now is\nintended to be more orthogonal and \"safer\" than the standard git\nporcelain. By \"safer\" I mean that yap will not perform an operation\nthat cannot be readily reversed without explicit confirmation (an \"-f\"\nflag, for instance). For example, the closest equivalent to \"git\nreset --hard\" in yap is \"yap point.\" yap point fails if there are any\nuncommitted changes (staged or unstaged), or if it would create\n\"dangling commits\" that can no longer be referenced by a ref (unless\n\"-f\" is given). On the orthogonal side, \"yap\" provides\ncommit/uncommit as a pair, as well as stage/unstage. They are small\nthings, but small things can make a big improvement in user experience\n(especially if it keeps you from killing uncommitted changes you had\nforgotten about).\n-- \n-Steven Walter \n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n -Robert Heinlein\n"},{"id":"90164","messageId":"5d46db230809082125v3ac7e36cx2cfd02fdfba0e987@mail.gmail.com","threadId":"15395","inReplyTo":"e06498070809081805l46ff295du69d8c9a2cc0ef59a@mail.gmail.com","subject":"Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain","fromName":"Govind Salinas","fromEmail":"govind@sophiasuchtig.com","sentAt":"2008-09-09T04:25:00Z","receivedAt":"2008-09-09T04:25:00Z","isPatch":false,"sender":{"key":"govind@sophiasuchtig.com","avatar":null},"body":"On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter wrote:\n> On Sun, Sep 7, 2008 at 11:45 PM, Govind Salinas\n> wrote:\n>>>> To my knowledge, Pyrite does not support plugins.\n>>\n>> Depends on what you mean by plugins. There is a way to load what I call\n>> extensions that you can use to add commands or modify the way existing\n>> commands operate. It is crude at the moment but it works. I have a\n>> proof of concept extension/plugin that adds different ways of specifying\n>> revisions. I assume you mean something similar.\n>\n> That pretty well describes what I mean by a plugin system. Does your\n> system allow anything other than commands to be overridden? Do your\n> commands ever call other commands, and if so, will the overridden\n> method be called in that case?\n>\n\nYes, but this is where it gets crude. There are several things that happen.\n\nYou get an on_load() call that happens when the extension is loaded. You\ncan use that to add a command. You also get an on_before_command()\nand on_after_command() that get called when you might expect, you can\nuse this to do anything from alter command line parameter to post-\nprocessing etc. After that you have to hook methods, python makes this\npretty easy. There is a known hook point by convention in every command,\nafter that you have to know what you want to hook in the particular command.\n\n> Yap's plugin system is pretty nice (IMHO), but it was designed almost\n> exclusively as a means to an end: the svn plugin. With the svn\n> plugin, \"yap clone\" will accept an SVN url as readily as a git URL,\n> and the result it what you would expect if you had a git URL: a\n> full-history git clone of the svn repository with all branches and\n> tags. Obviously, the svn clone would be much slower than the\n> equivalent git command, but that's the price one pays in interacting\n> with svn. However, this \"yap\" repo can then be cloned, and all the\n> svn meta-information will be present in the new repository. This\n> means that the new repository can immediately be used for pushing\n> commits back to the original svn repository without any additional\n> configuration. Additionally, you can use an svn revision anywhere a\n> git committish can be used.\n>\n\nYou should be able to use the plugin system I have to hook the clone\ncommand and run something different in the event that you have a svn\nURL. You would probably do this on_before_command. This was\nactually something someone brought up in a pyrite thread a while\nback. That should not be complicated.\n\n> In a yap \"yap-svn\" clone, \"svn\" appears as just another remote. \"yap\n> push svn foo\" does the expected thing. Likewise for fetching and\n> updating. In theory a similarly parallel interface could be provided\n> to other SCMs. Facilitating users who track SVN repositories with git\n> was one of the majors goals of the yap project, and I encourage users\n> who do so to give yap a try.\n>\n>> I am currently not doing much work on the command line interface since\n>> people seemed to object to my ideas. Instead I am focusing on the gui\n>> instead. Since you say you are not going to keep the command lines\n>> compatible, what do you intend to do differently?\n>\n> The command-line interface has been my primary focus, as that is what\n> I and my co-workers usually use. The interface that yap has now is\n> intended to be more orthogonal and \"safer\" than the standard git\n> porcelain. By \"safer\" I mean that yap will not perform an operation\n> that cannot be readily reversed without explicit confirmation (an \"-f\"\n> flag, for instance). For example, the closest equivalent to \"git\n> reset --hard\" in yap is \"yap point.\" yap point fails if there are any\n> uncommitted changes (staged or unstaged), or if it would create\n> \"dangling commits\" that can no longer be referenced by a ref (unless\n> \"-f\" is given). On the orthogonal side, \"yap\" provides\n> commit/uncommit as a pair, as well as stage/unstage. They are small\n> things, but small things can make a big improvement in user experience\n> (especially if it keeps you from killing uncommitted changes you had\n> forgotten about).\n\nI had some very different ideas along the lines of reducing the number of\ncommands (where the commands do something similar just DWIM rather\nthan force me to remember or read docs on different commands), making\ncommands look similar to commands from other SCMs (revert should do\nwhat it does for me in all the other SCMs that I have used, which is to\ncheckout the HEAD copy into the working directory) and improve\nusability (WTF does \"..\" mean vs \"...\" and why is it different for different\ncommands, etc). Perhaps we can talk and see if there is enough room for\nboth our goals.\n\nA further goal of mine is to eventually help with the libgit project so that git\noperations can be done from inside they python process rather than a\nfork and exec. This is an optimization, but it can also be used to get rid\nof any scripting that remains in git, making it possible to have git on\nwindows without MSYS or cygwin. Pyrite is very ambitious, as you might\ntell from how long it has been taking me to do it.\n\n-Govind\n"}]}