On Sun, Sep 7, 2008 at 11:45 PM, Govind Salinas <govind@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> "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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
