GNOME Bugzilla – Bug 327980
GIT support
Last modified: 2009-08-15 18:40:50 UTC
I think support for GIT (http://www.kernel.org/pub/software/scm/git/) would be a great addition to this otherwise excellent tool.
Sorry, I have no way to test/maintain this. I suggest you ask on the git mailing list. Meld has a plugin system so it should be quite easy.
Batch close of old bugs.
Created attachment 77448 [details] [review] Git vc backend for meld Here's a module that implements git support for meld. Stephen, would you be opposed to including this with meld? It wasn't clear to me if you didn't want to include git support, or just weren't going to write it yourself.
To be clear, I would welcome a git module and maintainer, but am unwilling to be that person as I don't use git. Thanks for the work. Will you take maintainership of that file too?
(In reply to comment #4) > To be clear, I would welcome a git module and maintainer, but am unwilling to > be that person as I don't use git. > > Thanks for the work. Will you take maintainership of that file too? > I'd be happy to.
Hi James, I've taken some time to getting to look at this. It seems to use obsolete commands. Can you bring it up to date and I'll commit? Thanks.
Created attachment 95355 [details] [review] New vc git backend This is another implementation of a vc backend for git which doesn't use "cg" or obsolete commands. It was based of the bzr backend. I'm using meld and git on a daily basis, so I can take maintainership for this file.
Hi, Could you please commit this? If there's anything the patch lacks please let me know. José
Thanks for your patience, it's added to svn now. Would you like to announce it on the mailing list before a release is made?
Just announced. Thanks.
Created attachment 100550 [details] Support for displaying non-VC files and to preserve sort order I've updated your patch to include support for displaying non-Version controlled files and to preserve the sort order of modified/deleted/added files in the meld display.
Thanks John, what do you think José?
I like John changes, especially handling untracked files.
Hi, I'm seeing a couple of problems with both the SVN version and John's version of 2007-12-07. This is on both Fedora 7 and 8. I have a tree like: /tmp/src/foo.cc /tmp/src/suba/suba.cc in /tmp/src I did a git init, git add *, git commit. I can then modify the files or not, it doesn't affrect the results. test: (in /tmp/src) meld . result: works ok, but shows directory above what I expect test: (in /tmp/src) meld foo.cc result: barfs: [abcd@pooty src]$ ls foo.cc suba subb [abcd@pooty src]$ ~/src/gnome-svn/meld/meld foo.cc Traceback (most recent call last):
+ Trace 181422
ret = task()
diff = difffunc()
files = [ relpath(workdir, f) for f in files ]
assert p.startswith(pbase) AssertionError
assert p.startswith(pbase) AssertionError Traceback (most recent call last):
meldapp.main()
app.main()
gtk.main()
than that for me. I thought I'd post now rather than wait for time to have another hack at it. Andrew.
Created attachment 100739 [details] [review] Change tabs to spaces in my previous version as per meld coding standards
Created attachment 100740 [details] [review] Add support for reporting ignored files. This should complete support for meld UI features in the git plugin.
(In reply to comment #14) > Hi, > > I'm seeing a couple of problems with both the SVN version > and John's version of 2007-12-07. This is on both Fedora 7 and 8. > > I have a tree like: > /tmp/src/foo.cc > /tmp/src/suba/suba.cc > in /tmp/src I did a git init, git add *, git commit. > I can then modify the files or not, it doesn't affrect the results. > > test: (in /tmp/src) > meld . > result: > works ok, but shows directory above what I expect Are you looking at it correctly (I was confused at first). Try with Flatten off and then open the suba directory. It looks fine to me. > > test: (in /tmp/src) > meld foo.cc > result: > barfs: > [abcd@pooty src]$ ls > foo.cc suba subb > [abcd@pooty src]$ ~/src/gnome-svn/meld/meld foo.cc > Traceback (most recent call last): > File "/home/abcd/src/gnome-svn/meld/task.py", line 131, in iteration > ret = task() > File "/home/abcd/src/gnome-svn/meld/vcview.py", line 298, in run_diff_iter > diff = difffunc() > File "/home/abcd/src/gnome-svn/meld/vcview.py", line 356, in _command_iter > files = [ relpath(workdir, f) for f in files ] > File "/home/abcd/src/gnome-svn/meld/vcview.py", line 349, in relpath > assert p.startswith(pbase) > AssertionError I've reproduced this one but haven't time to look into it tonight. Will try again tomorrow. I'll try the other tests then as well. I think this is a problem with specifying file names as 'meld suba' works fine. I have git 1.5.3.7 (kernel.org git) and 1.5.3.3 (CentOS5 RPM) to test with.
>> test: (in /tmp/src) >> meld . >> result: >> works ok, but shows directory above what I expect > Are you looking at it correctly (I was confused at first). Try with > Flatten off and then open the suba directory. It looks fine to me. My bad, it's working as it should for that test. I have git 1.5.3.4-1 from the Fedora rpm.
Created attachment 100798 [details] [review] Deal with relative filename args and only list unversioned dir not contents This looks like a problem with the get_working_dir API. My fix only works when meld is run from the root dir. If run from a subdir it still doesn't work unless a full pathname is provided (or a directory). This is a problem for all vc plugins that have a root dir (e.g. bzr, ...) instead of a dir for every source dir (e.g. CVS, SVN).
My patch in comment #19 should fix the bug in #14 (within the limits of the get_working_directory() API). Jose, Stephen, does this look good? Can we check my set of patches into SVN? What about all the root-dir based vc plugins that will have this same bug? I don't use them so I can't test a fix--though I think the same fix will work for them (with the same limitation). A complete fix will need a change to the get_working_directory() API. This fix is an improvement in any case.
Patches in comment #15 and comment #16 look good and can be applied. I need more time to look into comment #14 and comment #19 before I can make an opinion. I'll get back on that ASAP.
Created attachment 100865 [details] [review] Correctly report files in an unversioned directory as unversioned This implements the correct behaviour for files in an unversioned directory which is to report the files as unversioned (not as normal).
After applying the patches in #15, #16 and #19 test: (in /tmp/src) meld . result: good (never was a problem, my bad) test: (in /tmp/src) meld foo.cc result: good test: (in /tmp/src/suba) meld suba.cc result: barfs [abcd@pooty suba]$ ~/src/gnome-svn/meld/meld suba.cc Traceback (most recent call last):
+ Trace 181738
self.show_patch(prefix, patch)
misc.run_dialog( _("Invoking patch failed, you need GNU patch.")+ "\n'%s'"%" ".join(patchcmd), parent=self)
d.set_transient_for(parent.widget.get_toplevel())
I understand this might need a change to the plugin API to fix. test: (int /tmp/src/suba) meld . double click on suba result: good test: (anywhere) meld complete path to file result: still works fine Thanks for the fixes so far!
Created attachment 101083 [details] Updated git support, with simpler implementation. I've reimplemented most of lookup_tree() and lookup_files() functions with all the requested functionality but in a much simpler way (it doesn't need git-ls-files at all, just git-status --untracked-files). Also, John's patch to preserve sort order will miss removed files. This patch fixes that. This patch also handles "renamed" and "copied" files. Please test this new version.
Created attachment 101084 [details] Updated git support, with simpler implementation. Fixes just a regression when using meld outside the git workdir.
Created attachment 101119 [details] Updated git support, with simpler implementation (take 3) Fix a regression when passing files to meld, using John's fix in comment #19.
Stephen, I've been using this patch (from comment #26) locally without any problems for quite some time now. Please commit when you find the time, and close this bug. P.S.: When there is another git-support related bug then lets open another bug report, otherwise it's going to get quite difficult to understand what are the relevant patches/comments.
Thanks José, committed to svn.