GNOME Bugzilla – Bug 529270
GSoc: Git Plugin
Last modified: 2008-09-01 10:10:48 UTC
This bug will track the progress of Anjuta's git plugin for Google Summer of code. The code itself will be kept in a git repository until it's finished and ready for SVN trunk. The repository can be browsed online at http://repo.or.cz/w/anjuta-git-plugin.git. You can grab a copy of the code by installing git and running git clone git://repo.or.cz/anjuta-git-plugin.git. When the plugin is complete, a patch will be made and attached to this bug.
*** Bug 530304 has been marked as a duplicate of this bug. ***
Created attachment 112966 [details] Alpha 1 release of git plugin This is the first alpha release of my git plugin. It's not quite feature complete, but it's very close. This version supports these features from the proposal: - Rebasing - Fetching - Merging branches - Creating branches and tags - Deleting branches - Adding and removing files - Reverting uncommitted changes - Resolving conflicts - Committing changes - Reverting commits - Bisecting - Log viewer with revision graph and filtering - Diffing uncommitted changes - Showing diffs of commits What's not done yet: - Ignoring files - Remote branch handling - Pushing - Generating patch series - Getting files at any revision AFAICT everything implemented works well. But I have noticed some crashes if you load the Subversion plugin at some point with this plugin, but I'm not sure about it. I'd appreciate if someone could confirm this problem... Also, I really need people to test this with various git versions to see how the plugin handles them. And, when reporting problems, *always* make sure to specify what version of git you have. Apply the patch with -p 1 in the source tree root, and place the icon in the plugins/git directory after patching.
Your code looks very good. Couple of things happened when I tried it first in anjuta svn. It failed to load at first because ianjuta_file_get_uri() was renamed to ianjuta_file_get_file(). Changing that in in your plugin.c made it load and work. When I tried 'Git->Fetch', it segfaulted with the error message "GLib-GObject-WARNING **: invalid cast from `GitFetchCommand' to `SvnCommand'". Otherwise, they look quite fine. Would you want me to commit it in svn trunk to give others a chance to try?
(In reply to comment #3) > Your code looks very good. Couple of things happened when I tried it first in > anjuta svn. It failed to load at first because ianjuta_file_get_uri() was > renamed to ianjuta_file_get_file(). Changing that in in your plugin.c made it > load and work. When I tried 'Git->Fetch', it segfaulted with the error message > "GLib-GObject-WARNING **: invalid cast from `GitFetchCommand' to `SvnCommand'". Honestly, I don't really know what's causing this. I've searched through the patch and there aren't any casts to SvnCommand anywhere that I can see. This seems to be a problem only if the Subversion plugin was loaded first. If you unload it and restart anjuta, fetch, and any other command that uses info panes should work again. You might also notice that this bug shows itself in reverse too. If you load the git plugin first, do something with it, and then switch over to something that uses Subversion, that plugin will crash trying to cast to GitCommand, yet there are no references to Git in that plugin either. Could we be dealing with a broader Anjuta bug here, or can you see some mistake I'm making with the info pane? As for the interface changes, I'll make sure to commit a fix for that and get a new alpha patch out. > Otherwise, they look quite fine. Would you want me to commit it in svn trunk to > give others a chance to try? You can if you would like, but because of the nasty crasher bug above I'm not really sure it's ready for that yet...
Created attachment 114515 [details] Alpha 2 release of git plugin This release adapts to some recent changes to the IAnjutaFile interface so that the plugin will load again, namely that it now works with GFiles instead of URIs. Also added support for ignoring files and adding and removing remote branches. Ok, I'll admit it: I've been a little lazy these past couple of weeks so I'm a little behind, but it'll still get done way before August :-)
(In reply to comment #4) > (In reply to comment #3) > > Your code looks very good. Couple of things happened when I tried it first in > > anjuta svn. It failed to load at first because ianjuta_file_get_uri() was > > renamed to ianjuta_file_get_file(). Changing that in in your plugin.c made it > > load and work. When I tried 'Git->Fetch', it segfaulted with the error message > > "GLib-GObject-WARNING **: invalid cast from `GitFetchCommand' to `SvnCommand'". > Honestly, I don't really know what's causing this. I've searched through the > patch and there aren't any casts to SvnCommand anywhere that I can see. This > seems to be a problem only if the Subversion plugin was loaded first. > Here is the backtrace of the crash: (anjuta:32060): GLib-GObject-WARNING **: invalid cast from `GitFetchCommand' to `SvnCommand' Program received signal SIGSEGV, Segmentation fault.
+ Trace 202978
Thread 3067041568 (LWP 32060)
Looking at the trace, the object (of class GitCommand) seems to be doing fine until frame #6. After that something got corrupted and the signal ended up being emitted in the wrong object (of class SvnCommand). Both the classes share the same parents (namely AnjutaSyncClass and AnjutaClass). I think there is something wrong happening in either of the two parents's impl.
(In reply to comment #6) > Looking at the trace, the object (of class GitCommand) seems to be doing fine > until frame #6. After that something got corrupted and the signal ended up > being emitted in the wrong object (of class SvnCommand). Both the classes share > the same parents (namely AnjutaSyncClass and AnjutaClass). I think there is > something wrong happening in either of the two parents's impl. That's not quite right...SvnCommand derives from AnjutaAsyncCommand (multithreaded); GitCommand derives from AnjutaSyncCommand (synchronous). It's more likely a connected signal that's hanging around when it really shouldn't be. Notice that there's a g_signal_emit_call in that stack, and that's usually indicative of a closure calling a signal handler.
(In reply to comment #7) > That's not quite right...SvnCommand derives from AnjutaAsyncCommand > (multithreaded); GitCommand derives from AnjutaSyncCommand (synchronous). It's > more likely a connected signal that's hanging around when it really shouldn't > be. Notice that there's a g_signal_emit_call in that stack, and that's usually > indicative of a closure calling a signal handler. I think I have found the source of the problem. What's happening here is that both the SVN and Git plugins use a stock function called on_command_info_arrived to populate the message view with messages as they become available. I read on the TODO list some time ago that plugins aren't unloaded when they're deactivated, so a plugin, and it's functions, stay resident in memory. Apparently this can confuse the module loader such that if two plugins have functions with the same name and signature, Anjuta will call whichever function that was loaded first. The solution to this problem is to give each plugin's stock functions a namespace, i.e. on_command_info_arrived becomes on_git_command_info_arrived. If I make this change, the crash disappears. However, I'll have to change the names of almost every utility function for this plugin, and the Subversion plugin. I'll work on the git plugin for now, but it's going to take me a little bit to fix everything. I'll see if I can commit the fix to git by tomorrow or the next day.
Created attachment 115227 [details] Alpha 3 release of git plugin This release should build against latest SVN trunk, with some changes to support Seb's recent changes to AnjutaLauncher. I've also fixed the crashes and other odd behavior that results from using this plugin and the Subversion one in the same session. In short, the problem was fixed by putting all of the git plugin's UI utility functions in the "git" namespace so they didn't conflict with the Subversion functions, which are still in memory even after that plugin is unloaded. With this issue resolved I consider this plugin stable enough for most day-to-day use. On the features front, I've implemented patch series creation and pulling in this release. The only thing left to do is getting files at any revision, and that'll do it as far as the proposal goes. :-) Once I get that completed, and in the process get some decent FM integration going, I'll release a beta for testing.
(In reply to comment #9) > Created an attachment (id=115227) [edit] > On the features front, I've implemented patch series creation and pulling in > this release. The only thing left to do is getting files at any revision, and > that'll do it as far as the proposal goes. :-) Once I get that completed, and > in the process get some decent FM integration going, I'll release a beta for > testing. > Hi James, great work :). I would like to commit it in svn if you agree. I think it is already good now and you will also get some feedbacks from people using anjuta from svn. Besides, it will make it easy to submit following patches. Thanks.
(In reply to comment #10) > (In reply to comment #9) > > Created an attachment (id=115227) [edit] > > On the features front, I've implemented patch series creation and pulling in > > this release. The only thing left to do is getting files at any revision, and > > that'll do it as far as the proposal goes. :-) Once I get that completed, and > > in the process get some decent FM integration going, I'll release a beta for > > testing. > > > Hi James, great work :). I would like to commit it in svn if you agree. I think > it is already good now and you will also get some feedbacks from people using > anjuta from svn. Besides, it will make it easy to submit following patches. > > Thanks. That's fine with me, especially seeing that feature freeze is today, so go ahead and commit. I'm still working on getting file blobs. I'm almost done with that, but due to various reasons, including some laziness on my part, I'm way behind on it. I hope to get it done today, but I don't have a problem with putting it in SVN afterward if you don't. Thanks, James
(In reply to comment #11) > That's fine with me, especially seeing that feature freeze is today, so go > ahead and commit. Committed. It really looks good. Thanks a lot! > I'm still working on getting file blobs. I'm almost done with > that, but due to various reasons, including some laziness on my part, I'm way > behind on it. I hope to get it done today, but I don't have a problem with > putting it in SVN afterward if you don't. > No problem, take your time :)
Created attachment 116023 [details] [review] Beta 1 patch This patch should be applied to SVN trunk to upgrade the git plugin to Beta 1. Beta 1 completes the agreed-upon feature set in the proposal. Specifically, this patch adds: - Support for viewing logs of individual files or folders - Support for viewing files at any revision (or "blobs" as git calls them) - File manager integration for log viewing and adding and removing files This release also fixes some minor bugs: - Fixes problems with input checking, error dialogs, and widget focusing when user doesn't enter a path in the log viewer when not viewing the log of the whole project - Memory leak fixes - Copyright header fixes It's finally done!! :-)
Created attachment 116025 [details] [review] Beta 1 patch (fixed) Please ignore that last one. It contains changes to my personal TODO list that probably won't apply to SVN. This one should be clean. Sorry for the noise...
All patches have been committed to SVN trunk for release in 2.6. I just tested a fresh checkout of SVN and everything seems to work fine, so I consider this bug to be fixed. If you encounter any bugs with this plugin, please file bug reports against the "plugins: git" component.
Thanks James. Great job. I have submitted the end-term report as well. Closing the bug report. Let's continue in plugins:git component for further bug reports.