Re: "meld ." broken when using git?

[Kai Willadsen <kai willadsen gmail com>]

2010/1/9 Grant Edwards <grant b edwards gmail com>:
> 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