On Thu, Sep 27, 2012 at 7:22 PM, Drew Northup <n1xim.em...@gmail.com> wrote: >>> 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. >> 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
