{"thread":{"id":"31650","subject":"DWIM .git repository discovery","startedAt":"2012-09-26T01:49:42Z","lastAt":"2012-09-27T18:20:30Z","messageCount":7,"participants":["Nguyen Thai Ngoc Duy","Junio C Hamano","Michael J Gruber","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"199922","messageId":"CACsJy8DOtPWgkq=KSHCb=J3qg4o1aPaLo4aj7U5f_qa+kCCipQ@mail.gmail.com","threadId":"31650","inReplyTo":null,"subject":"DWIM .git repository discovery","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-26T01:49:42Z","receivedAt":"2012-09-26T01:49:42Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nI often find myself attempting to examine another repository,\nespecially in projects that are closely related but put in different\ngit repos. It's usually just a diff or log command\n\ngit log --patch ../path/to/another/repo/path/to/file.c\n\ncd'ing out is nuisance for one-shot commands, even setting --git-dir\nis because i'd need to repeat the path. I think when we detect paths\noutside repository, we could try to discover new repository that\ncontain those paths, the adjust $GIT_DIR internally to the new\nrepository.\n\nWe can't do that now because .git repository and \"path outside\nrepository\" check occur in two separate stages, the latter after .git\nis discovered and .git can't be moved once discovered. We might be\nable to move \"path outside repo\" check up to discovery phase. But that\ncould be big change.\n\nDoes anybody want such a feature, or it's just my itch? It's probably\nnot worth doing because few people need it.\n-- \nDuy\n"},{"id":"199925","messageId":"7v7grhv2fu.fsf@alter.siamese.dyndns.org","threadId":"31650","inReplyTo":"CACsJy8DOtPWgkq=KSHCb=J3qg4o1aPaLo4aj7U5f_qa+kCCipQ@mail.gmail.com","subject":"Re: DWIM .git repository discovery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-26T04:21:57Z","receivedAt":"2012-09-26T04:21:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> I often find myself attempting to examine another repository,\n> especially in projects that are closely related but put in different\n> git repos. It's usually just a diff or log command\n>\n> git log --patch ../path/to/another/repo/path/to/file.c\n\nI personally do not think it is _too_ bad to internally do\n\n\t(cd ../path/to/another/repo/path/to &&\n\t git log --patch file.c)\n\nbut I doubt it is worth the numerous implications (I am not talking\nabout implementation complexity at all, but the conceptual burden).\n\nFor example, where in the working tree of the other project should\nthe command run? The output from \"log -p\" happens to be always\nrelative to the top of the working tree, but that does not\nnecessarily hold true for other subcommands.\n\nA worse thing is that there is an oddball case \"diff[ --no-index]\"\nthat changes behaviour depending on the pathspec points at inside or\noutside the repository.\n\nI think that this is a road to insanity; anybody who thinks along\nthis line is already on the other side of the line, I would have to\nsay ;-).\n"},{"id":"199927","messageId":"5062AEA5.9000903@drmicha.warpmail.net","threadId":"31650","inReplyTo":"7v7grhv2fu.fsf@alter.siamese.dyndns.org","subject":"Re: DWIM .git repository discovery","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-26T07:28:37Z","receivedAt":"2012-09-26T07:28:37Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 26.09.2012 06:21:\n> Nguyen Thai Ngoc Duy writes:\n> \n>> I often find myself attempting to examine another repository,\n>> especially in projects that are closely related but put in different\n>> git repos. It's usually just a diff or log command\n>>\n>> git log --patch ../path/to/another/repo/path/to/file.c\n> \n> I personally do not think it is _too_ bad to internally do\n> \n> \t(cd ../path/to/another/repo/path/to &&\n> \t git log --patch file.c)\n> \n> but I doubt it is worth the numerous implications (I am not talking\n> about implementation complexity at all, but the conceptual burden).\n\nYeah, but doing the above from an alias or help script should be fine\nand can be tailored to your use case. Say, a script like\n\narg1=\"$1\"\nshift\ncd $(dirname \"$arg1\")\ngit \"$@\" $(basename \"$args1\")\n\nshould cover a couple of use cases already. (Error checking is for the\nfaint of heart only.)\n\n> For example, where in the working tree of the other project should\n> the command run? The output from \"log -p\" happens to be always\n> relative to the top of the working tree, but that does not\n> necessarily hold true for other subcommands.\n> \n> A worse thing is that there is an oddball case \"diff[ --no-index]\"\n> that changes behaviour depending on the pathspec points at inside or\n> outside the repository.\n> \n> I think that this is a road to insanity; anybody who thinks along\n> this line is already on the other side of the line, I would have to\n> say ;-).\n> \n\nDon't we all just walk on the line?\n\nMichael\n"},{"id":"199936","messageId":"CACsJy8B5xXSrqoYX_5BW34Sq0QpP6U=E6e+prJRe_0FWf4Bz0w@mail.gmail.com","threadId":"31650","inReplyTo":"7v7grhv2fu.fsf@alter.siamese.dyndns.org","subject":"Re: DWIM .git repository discovery","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-26T11:02:23Z","receivedAt":"2012-09-26T11:02:23Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano wrote:\n> Nguyen Thai Ngoc Duy writes:\n>\n>> I often find myself attempting to examine another repository,\n>> especially in projects that are closely related but put in different\n>> git repos. It's usually just a diff or log command\n>>\n>> git log --patch ../path/to/another/repo/path/to/file.c\n>\n> I personally do not think it is _too_ bad to internally do\n>\n> (cd ../path/to/another/repo/path/to &&\n> git log --patch file.c)\n>\n\nAs long as the .git discovery and path rewriting can be done\nautomatically, that'd be nice. But..\n\n> but I doubt it is worth the numerous implications (I am not talking\n> about implementation complexity at all, but the conceptual burden).\n>\n> For example, where in the working tree of the other project should\n> the command run? The output from \"log -p\" happens to be always\n> relative to the top of the working tree, but that does not\n> necessarily hold true for other subcommands.\n\nReturned paths should always be relative to cwd (well except diff/log\nwhich are prefixed by [ab]/). cd'ing internally like above makes it\nmore confusing imo. Take grep for example, I find it natural for \"git\ngrep foo -- ../other/repo/bar/\" to return \"../other/repo/bar/foo.c\n...\".\n\nPrefix currently does not take \"../blah\" form, but I see no reasons\nwhy it can't/shouldn't. $(cwd) is most likely outside the other\nproject's working directory. An exception running from inside a\nsubmodule and examining the parent repository.\n\nFor too long relative paths, we could even display in \":/\" pathspec\nnotation. Users who don't recognize them either look up documentation,\nor gradually learn to drop the \":/\" part, even without know what it's\nfor.\n\nRepo modification commands like git-add could cause greater confusion\n(I added and committed it (on the other repo), but when I pushed (on\nthis repo), the changes aren't there). We could and probably should\navoid dwim-ing these cases.\n\nA good way to make it clear you're accessing another repository is\nprompt (y/n) from users. I don't think pressing Ctrl-C to abort the\ncommand is too much hassle (the command would fail anyway with\n\"outside repository\" message, without dwim).\n\n> A worse thing is that there is an oddball case \"diff[ --no-index]\"\n> that changes behaviour depending on the pathspec points at inside or\n> outside the repository.\n\nYep. But not many commands do this fortunately (diff and grep only?)\n\n> I think that this is a road to insanity; anybody who thinks along\n> this line is already on the other side of the line, I would have to\n> say ;-).\n\nWe could go slowly and stop before being diagnosed insane. I mean the\ntrick can be opted in for a command subset where it makes sense to do\nso.\n-- \nDuy\n"},{"id":"200008","messageId":"CAM9Z-nkCos979Kte+k+wYKZMzo625JhWjmye2zraPKk0BgTHmw@mail.gmail.com","threadId":"31650","inReplyTo":"CACsJy8B5xXSrqoYX_5BW34Sq0QpP6U=E6e+prJRe_0FWf4Bz0w@mail.gmail.com","subject":"Re: DWIM .git repository discovery","fromName":"Drew Northup","fromEmail":"n1xim.email@gmail.com","sentAt":"2012-09-27T12:22:55Z","receivedAt":"2012-09-27T12:22:55Z","isPatch":false,"sender":{"key":"n1xim.email@gmail.com","avatar":null},"body":"On Wed, Sep 26, 2012 at 7:02 AM, Nguyen Thai Ngoc Duy wrote:\n> On Wed, Sep 26, 2012 at 11:21 AM, Junio C Hamano wrote:\n>> Nguyen Thai Ngoc Duy writes:\n>>\n>>> I often find myself attempting to examine another repository,\n>>> especially in projects that are closely related but put in different\n>>> git repos. It's usually just a diff or log command\n>>>\n>>> git log --patch ../path/to/another/repo/path/to/file.c\n>>\n>> I personally do not think it is _too_ bad to internally do\n>>\n>> (cd ../path/to/another/repo/path/to &&\n>> git log --patch file.c)\n>>\n>\n> As long as the .git discovery and path rewriting can be done\n> automatically, that'd be nice. But..\n\nI do not think that it should be the job of Git to guess how you would\nlike your paths recannonicalized. That is truly a pathway to insanity.\n\n>> but I doubt it is worth the numerous implications (I am not talking\n>> about implementation complexity at all, but the conceptual burden).\n>>\n>> For example, where in the working tree of the other project should\n>> the command run? The output from \"log -p\" happens to be always\n>> relative to the top of the working tree, but that does not\n>> necessarily hold true for other subcommands.\n\nAnd for us to presume that changing how all of those operate now by\ndefault would be a good idea is most definitely folly.\n\n> Returned paths should always be relative to cwd (well except diff/log\n> which are prefixed by [ab]/). cd'ing internally like above makes it\n> more confusing imo. Take grep for example, I find it natural for \"git\n> grep foo -- ../other/repo/bar/\" to return \"../other/repo/bar/foo.c\n> ...\".\n\nIn Junio's example it would be relative to the working directory—of\nthe subshell. Neither the shell nor Git is in a position to clean that\nup much if at all.\n\n> Prefix currently does not take \"../blah\" form, but I see no reasons\n> why it can't/shouldn't. $(cwd) is most likely outside the other\n> project's working directory. An exception running from inside a\n> submodule and examining the parent repository.\n\nIs hacking the master project code from inside of a submodule what\nthis is actually about?\n\n> For too long relative paths, we could even display in \":/\" pathspec\n> notation. Users who don't recognize them either look up documentation,\n> or gradually learn to drop the \":/\" part, even without know what it's\n> for.\n>\n> Repo modification commands like git-add could cause greater confusion\n> (I added and committed it (on the other repo), but when I pushed (on\n> this repo), the changes aren't there). We could and probably should\n> avoid dwim-ing these cases.\n\nI think you just made a decent case for not doing too much \"DWIM\"\nhere. \"DWIM\" is a very fraught concept because you are assuming that\neverybody is going to want to do things exactly (or nearly so) the way\nyou do.\n\n>> I think that this is a road to insanity; anybody who thinks along\n>> this line is already on the other side of the line, I would have to\n>> say ;-).\n>\n> We could go slowly and stop before being diagnosed insane. I mean the\n> trick can be opted in for a command subset where it makes sense to do\n> so.\n\nI would recommend stopping now then.\n\n-- \n-Drew Northup\n--------------------------------------------------------------\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"200009","messageId":"CACsJy8CaWjV+is0WKh2kYiNfHOkN0M_Hs2wXzH3DUMtUeKMTAQ@mail.gmail.com","threadId":"31650","inReplyTo":"CAM9Z-nkCos979Kte+k+wYKZMzo625JhWjmye2zraPKk0BgTHmw@mail.gmail.com","subject":"Re: DWIM .git repository discovery","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-27T12:38:04Z","receivedAt":"2012-09-27T12:38:04Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Sep 27, 2012 at 7:22 PM, Drew Northup wrote:\n>>> I personally do not think it is _too_ bad to internally do\n>>>\n>>> (cd ../path/to/another/repo/path/to &&\n>>> git log --patch file.c)\n>>>\n>>\n>> As long as the .git discovery and path rewriting can be done\n>> automatically, that'd be nice. But..\n>\n> I do not think that it should be the job of Git to guess how you would\n> like your paths recannonicalized. That is truly a pathway to insanity.\n\nI believe we are doing that. We move cwd internally to top worktree,\nso we rewrite (well, prefix) all paths.\n\n>> Returned paths should always be relative to cwd (well except diff/log\n>> which are prefixed by [ab]/). cd'ing internally like above makes it\n>> more confusing imo. Take grep for example, I find it natural for \"git\n>> grep foo -- ../other/repo/bar/\" to return \"../other/repo/bar/foo.c\n>> ...\".\n>\n> In Junio's example it would be relative to the working directory—of\n> the subshell. Neither the shell nor Git is in a position to clean that\n> up much if at all.\n\nThat's implementation details.\n\n>> Prefix currently does not take \"../blah\" form, but I see no reasons\n>> why it can't/shouldn't. $(cwd) is most likely outside the other\n>> project's working directory. An exception running from inside a\n>> submodule and examining the parent repository.\n>\n> Is hacking the master project code from inside of a submodule what\n> this is actually about?\n\nHacking, no. Examining, yes. And in my case, no submodules. It's gnome\nprojects where a bunch of libraries (in their own repositories) may be\nneeded for an application. I stay in the application directory but\nfrom time to time I'll need to look outside in other repositories.\n-- \nDuy\n"},{"id":"200032","messageId":"7v7grfqqdt.fsf@alter.siamese.dyndns.org","threadId":"31650","inReplyTo":"CAM9Z-nkCos979Kte+k+wYKZMzo625JhWjmye2zraPKk0BgTHmw@mail.gmail.com","subject":"Re: DWIM .git repository discovery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-27T18:20:30Z","receivedAt":"2012-09-27T18:20:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Drew Northup writes:\n\n>>> I think that this is a road to insanity; anybody who thinks along\n>>> this line is already on the other side of the line, I would have to\n>>> say ;-).\n>>\n>> We could go slowly and stop before being diagnosed insane. I mean the\n>> trick can be opted in for a command subset where it makes sense to do\n>> so.\n>\n> I would recommend stopping now then.\n\nLikewise. Didn't I already diagnose it as insane? ;-)\n"}]}