Re: DWIM .git repository discovery

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Sep 26, 2012, 11:02 UTC
Message-ID: <CACsJy8B5xXSrqoYX_5BW34Sq0QpP6U=E6e+prJRe_0FWf4Bz0w@mail.gmail.com>
In-Reply-To: <7v7grhv2fu.fsf@alter.siamese.dyndns.org>

On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> I often find myself attempting to examine another repository,
>> especially in projects that are closely related but put in different
>> git repos. It's usually just a diff or log command
>>
>> git log --patch ../path/to/another/repo/path/to/file.c
>
> 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..

Show 7 quoted lines

> but I doubt it is worth the numerous implications (I am not talking
> about implementation complexity at all, but the conceptual burden).
>
> For example, where in the working tree of the other project should
> the command run?  The output from "log -p" happens to be always
> relative to the top of the working tree, but that does not
> necessarily hold true for other subcommands.

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

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.

For too long relative paths, we could even display in ":/" pathspec notation. Users who don't recognize them either look up documentation, or gradually learn to drop the ":/" part, even without know what it's for.

Repo modification commands like git-add could cause greater confusion (I added and committed it (on the other repo), but when I pushed (on this repo), the changes aren't there). We could and probably should avoid dwim-ing these cases.

A good way to make it clear you're accessing another repository is prompt (y/n) from users. I don't think pressing Ctrl-C to abort the command is too much hassle (the command would fail anyway with "outside repository" message, without dwim).

> A worse thing is that there is an oddball case "diff[ --no-index]"
> that changes behaviour depending on the pathspec points at inside or
> outside the repository.

Yep. But not many commands do this fortunately (diff and grep only?)

> I think that this is a road to insanity; anybody who thinks along
> this line is already on the other side of the line, I would have to
> say ;-).

We could go slowly and stop before being diagnosed insane. I mean the trick can be opted in for a command subset where it makes sense to do so.

-- 
Duy