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.
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