DWIM .git repository discovery

DWIM .git repository discovery

[Nguyen Thai Ngoc Duy]

Hi,

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

cd'ing out is nuisance for one-shot commands, even setting --git-dir
is because i'd need to repeat the path. I think when we detect paths
outside repository, we could try to discover new repository that
contain those paths, the adjust $GIT_DIR internally to the new
repository.

We can't do that now because .git repository and "path outside
repository" check occur in two separate stages, the latter after .git
is discovered and .git can't be moved once discovered. We might be
able to move "path outside repo" check up to discovery phase. But that
could be big change.

Does anybody want such a feature, or it's just my itch? It's probably
not worth doing because few people need it.
-- 
Duy

Re: DWIM .git repository discovery

[Junio C Hamano]

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)

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.

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.

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

Re: DWIM .git repository discovery

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 26.09.2012 06:21:
> 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)
> 
> but I doubt it is worth the numerous implications (I am not talking
> about implementation complexity at all, but the conceptual burden).

Yeah, but doing the above from an alias or help script should be fine
and can be tailored to your use case. Say, a script like

arg1="$1"
shift
cd $(dirname "$arg1")
git "$@" $(basename "$args1")

should cover a couple of use cases already. (Error checking is for the
faint of heart only.)

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

Don't we all just walk on the line?

Michael

Re: DWIM .git repository discovery

[Nguyen Thai Ngoc Duy]

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

> 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

Re: DWIM .git repository discovery

[Drew Northup]

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

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

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

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

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

Re: DWIM .git repository discovery

[Nguyen Thai Ngoc Duy]

On Thu, Sep 27, 2012 at 7:22 PM, Drew Northup <n1xim.email@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

Re: DWIM .git repository discovery

[Junio C Hamano]

Drew Northup <n1xim.email@gmail.com> writes:

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

Likewise.  Didn't I already diagnose it as insane? ;-)