Re: DWIM .git repository discovery

On Thu, Sep 27, 2012 at 7:22 PM, Drew Northup [off-list ref] wrote:

quoted

quoted

I personally do not think it is _too_ bad to internally do

        (cd ../path/to/another/repo/path/to &&
         git log --patch file.c)

As long as the .git discovery and path rewriting can be done
automatically, that'd be nice. But..

I do not think that it should be the job of Git to guess how you would
like your paths recannonicalized. That is truly a pathway to insanity.

I believe we are doing that. We move cwd internally to top worktree,
so we rewrite (well, prefix) all paths.

quoted

Returned paths should always be relative to cwd (well except diff/log
which are prefixed by [ab]/). cd'ing internally like above makes it
more confusing imo. Take grep for example, I find it natural for "git
grep foo -- ../other/repo/bar/" to return "../other/repo/bar/foo.c
...".

In Junio's example it would be relative to the working directory—of
the subshell. Neither the shell nor Git is in a position to clean that
up much if at all.

That's implementation details.

quoted

Prefix currently does not take "../blah" form, but I see no reasons
why it can't/shouldn't. $(cwd) is most likely outside the other
project's working directory. An exception running from inside a
submodule and examining the parent repository.

Is hacking the master project code from inside of a submodule what
this is actually about?

Hacking, no. Examining, yes. And in my case, no submodules. It's gnome
projects where a bunch of libraries (in their own repositories) may be
needed for an application. I stay in the application directory but
from time to time I'll need to look outside in other repositories.
-- 
Duy