On Wed, Sep 26, 2012 at 7:02 AM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html