2010/1/9 Grant Edwards <[email protected]>: > With CVS or SVN, doing a "meld <dirname>" only shows what's > changed underneath the specified directory. When you do that > specifying a subdirectory of a git working copy, meld scans the > entire working copy, and then shows you a view from what is > sometimes a _log_ way further up the diretory tree that what > you requested. > > This makes meld a lot less useful for two reasons: > > 1) For large projects, it can take a long time to scan the > entire project. This is especially annoying when the > directory you specified only contains a handful of files. > > 2) After the resulting wait, you end up with a lot of unwanted > clutter -- you've got to sift through the results to find > the results you requests. > > IOW, when I used CVS and SVN, "meld ." was a extremely useful > command. When usin git -- not so much. > > Is this a bug in the git support, a limitation of git itself, > or a design decision?
I didn't write the code, but I suspect that it's not a design decision. There is something to be said for always showing all changes in a repo, but it should at least be possible to restrict to a subset. Both SVN and CVS set VC_ROOT_WALK to false, turning off any attempt to find a SVN/CVS repo higher in the tree. This setting obviously doesn't cut it with git, as subdirectories of a git repo don't have their own .git directories/files, and we want to be able to start a VC comparison from subdirectories of a git repo. Off the top of my head, I suspect that this could be solved by making the checking and root-setting separate, though I don't know what side-effects this might have. Please file a bug (though I'm personally not likely to be able to work on it any time soon). cheers, Kai _______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
