From: Junio C Hamano <hidden> Date: 2016-06-15 22:54:52
Nguyen Thai Ngoc Duy [off-list ref] 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 ;-).
From: Michael J Gruber <hidden> Date: 2016-06-15 22:54:52
Junio C Hamano venit, vidit, dixit 26.09.2012 06:21:
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)
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 ;-).
On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano [off-list ref] wrote:
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..
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
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
On Thu, Sep 27, 2012 at 7:22 PM, Drew Northup [off-list ref] wrote:
quoted
quoted
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.
quoted
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.
quoted
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