Re: DWIM .git repository discovery

On Wed, Sep 26, 2012 at 7:02 AM, Nguyen Thai Ngoc Duy [off-list ref] wrote:

On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano [off-list ref] wrote:

quoted

Nguyen Thai Ngoc Duy [off-list ref] writes:

quoted

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.

quoted

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.

quoted

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