Re: DWIM .git repository discovery
On Wed, Sep 26, 2012 at 7:02 AM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DWIM .git repository discovery
On Thu, Sep 27, 2012 at 7:22 PM, Drew Northup n1xim.em...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DWIM .git repository discovery
Drew Northup n1xim.em...@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? ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DWIM .git repository discovery
Junio C Hamano venit, vidit, dixit 26.09.2012 06:21: Nguyen Thai Ngoc Duy pclo...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DWIM .git repository discovery
On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano gits...@pobox.com wrote: Nguyen Thai Ngoc Duy pclo...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DWIM .git repository discovery
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DWIM .git repository discovery
Nguyen Thai Ngoc Duy pclo...@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 ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
