Re: DWIM .git repository discovery

From: Drew Northup <n1xim.email@gmail.com>
Date: Sep 27, 2012, 12:22 UTC
Message-ID: <CAM9Z-nkCos979Kte+k+wYKZMzo625JhWjmye2zraPKk0BgTHmw@mail.gmail.com>
In-Reply-To: <CACsJy8B5xXSrqoYX_5BW34Sq0QpP6U=E6e+prJRe_0FWf4Bz0w@mail.gmail.com>

On Wed, Sep 26, 2012 at 7:02 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:

Show 17 quoted lines

> On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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..

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.

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.

And for us to presume that changing how all of those operate now by default would be a good idea is most definitely folly.

Show 5 quoted lines

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

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

Show 9 quoted lines

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

I think you just made a decent case for not doing too much "DWIM" here. "DWIM" is a very fraught concept because you are assuming that everybody is going to want to do things exactly (or nearly so) the way you do.

Show 7 quoted lines

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

I would recommend stopping now then.

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59