{"thread":{"id":"11346","subject":"log/show: relative pathnames do not work in rev:path","startedAt":"2007-12-18T17:33:21Z","lastAt":"2007-12-22T14:33:14Z","messageCount":43,"participants":["Alex Riesen","Jakub Narebski","Dana How","Linus Torvalds","Junio C Hamano","Johannes Schindelin","Jeff King","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"63646","messageId":"20071218173321.GB2875@steel.home","threadId":"11346","inReplyTo":null,"subject":"log/show: relative pathnames do not work in rev:path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T17:33:21Z","receivedAt":"2007-12-18T17:33:21Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Noticed by a collegue of mine. Consider:\n\n $ cd $GIT/t\n $ git show 570f32266:t/test-lib.sh # works\n $ git show 570f32266:test-lib.sh # does not work\n $ git show 570f32266:./test-lib.sh # does not work\n $ git show 570f32266:/t/test-lib.sh # does not work\n\nConsidering that the relative path names work as filters (and many\nagreed on that being useful), it would be nice to allow relative\npathnames in blob specifications for git-show and git-cat-file.\n\n(besides the colon is a good delimiter, even tab-completion works with it)\n"},{"id":"63648","messageId":"m3d4t3q4e5.fsf@roke.D-201","threadId":"11346","inReplyTo":"20071218173321.GB2875@steel.home","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-18T17:50:20Z","receivedAt":"2007-12-18T17:50:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Alex Riesen writes:\n\n> Noticed by a collegue of mine. Consider:\n> \n> $ cd $GIT/t\n> $ git show 570f32266:t/test-lib.sh # works\n> $ git show 570f32266:test-lib.sh # does not work\n> $ git show 570f32266:./test-lib.sh # does not work\n> $ git show 570f32266:/t/test-lib.sh # does not work\n> \n> Considering that the relative path names work as filters (and many\n> agreed on that being useful), it would be nice to allow relative\n> pathnames in blob specifications for git-show and git-cat-file.\n> \n> (besides the colon is a good delimiter, even tab-completion works with it)\n\nIf you think about it a bit, relative path names nor absolute\npath names does and should not work. 570f32266:t/test-lib.sh\nmeans path t/test-lib.sh staring from 570f32266^{tree}. Where\nyou are in the filesystem is not important and matters not for\nthis syntax. Besides if you access other branch file might be\nnot in filesystem (deleted file, or disjoint branch with separate\ncontents like 'todo' or 'html' branch in git.git repository).\n\nBesides,\n\n $ git show 570f32266:t/test-lib.sh # works\n $ git show cc5ac8b72:test-lib.sh # also works\n\nworks... but 49d8bcd7a2df5 here is SHA-1 id of a 't/' tree\n(shortened output of \"git rev-parse 570f32266:t\").\n\nAnd I think that with bash-completion from contrib you complete\ncorrect pathnames; don't rely on filesystem pathnames completion.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"63669","messageId":"20071218204623.GC2875@steel.home","threadId":"11346","inReplyTo":"m3d4t3q4e5.fsf@roke.D-201","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T20:46:23Z","receivedAt":"2007-12-18T20:46:23Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jakub Narebski, Tue, Dec 18, 2007 18:50:20 +0100:\n> Alex Riesen writes:\n> \n> > Noticed by a collegue of mine. Consider:\n> > \n> > $ cd $GIT/t\n> > $ git show 570f32266:t/test-lib.sh # works\n> > $ git show 570f32266:test-lib.sh # does not work\n> > $ git show 570f32266:./test-lib.sh # does not work\n> > $ git show 570f32266:/t/test-lib.sh # does not work\n> > \n> > Considering that the relative path names work as filters (and many\n> > agreed on that being useful), it would be nice to allow relative\n> > pathnames in blob specifications for git-show and git-cat-file.\n> > \n> > (besides the colon is a good delimiter, even tab-completion works with it)\n> \n> If you think about it a bit, relative path names nor absolute\n> path names does and should not work. 570f32266:t/test-lib.sh\n> means path t/test-lib.sh staring from 570f32266^{tree}. Where\n> you are in the filesystem is not important and matters not for\n> this syntax. Besides if you access other branch file might be\n> not in filesystem (deleted file, or disjoint branch with separate\n> contents like 'todo' or 'html' branch in git.git repository).\n\nNot convinced. It is *not* the plumbing problem I was trying to\ndescribe. They discussion, metaphorically, should not have left the\ncommand-line parser.\n\nI think that we have parsing of the blob locators at the wrong level:\nso that git-show, git-log and git-diff can handle its pathnames as\nthey handle path filters (relative to cwd), and git-cat-file,\ngit-diff-tree, git-rev-list, etc can handle theirs always relative to\nthe project root.\n\nI actually do not see any problem for git-show (being porcelain-level\nprogram) to treat *each and every* path anywhere relatively to the\ncurrent directory. It is just more comfortable.\n\nPlease consider the following patches.\n"},{"id":"63671","messageId":"20071218204752.GD2875@steel.home","threadId":"11346","inReplyTo":"20071218204623.GC2875@steel.home","subject":"[PATCH] Simple support for tree entry specification with relative pathnames","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T20:47:52Z","receivedAt":"2007-12-18T20:47:52Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"This allows git show to understand something like this:\n\n $ test -f DIR/file && cd DIR && git show rev:file\n\nSigned-off-by: Alex Riesen \n---\n\nThis is a bit too simplistic and can be fooled easily:\n\n .../t$ git show HEAD:../t/test-lib.sh\n\nwont work. It is short, though.\n\n cache.h | 1 +\n revision.c | 4 ++--\n sha1_name.c | 27 ++++++++++++++++++++++++---\n 3 files changed, 27 insertions(+), 5 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 39331c2..054f106 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -416,6 +416,7 @@ static inline unsigned int hexval(unsigned char c)\n \n extern int get_sha1(const char *str, unsigned char *sha1);\n extern int get_sha1_with_mode(const char *str, unsigned char *sha1, unsigned *mode);\n+extern int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sha1, unsigned *mode);\n extern int get_sha1_hex(const char *hex, unsigned char *sha1);\n extern char *sha1_to_hex(const unsigned char *sha1);\t/* static buffer result! */\n extern int read_ref(const char *filename, unsigned char *sha1);\ndiff --git a/revision.c b/revision.c\nindex 7e2f4f1..cac283c 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -855,7 +855,7 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,\n \t\tlocal_flags = UNINTERESTING;\n \t\targ++;\n \t}\n-\tif (get_sha1_with_mode(arg, sha1, &mode))\n+\tif (get_sha1_with_prefix(revs->prefix, arg, sha1, &mode))\n \t\treturn -1;\n \tif (!cant_be_filename)\n \t\tverify_non_filename(revs->prefix, arg);\n@@ -1280,7 +1280,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\tunsigned char sha1[20];\n \t\tstruct object *object;\n \t\tunsigned mode;\n-\t\tif (get_sha1_with_mode(def, sha1, &mode))\n+\t\tif (get_sha1_with_prefix(revs->prefix, def, sha1, &mode))\n \t\t\tdie(\"bad default revision '%s'\", def);\n \t\tobject = get_reference(revs, def, sha1, 0);\n \t\tadd_pending_object_with_mode(revs, object, def, mode);\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 13e1164..358aab7 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -656,6 +656,12 @@ int get_sha1(const char *name, unsigned char *sha1)\n \n int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n {\n+\treturn get_sha1_with_prefix(NULL, name, sha1, mode);\n+}\n+\n+int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sha1, unsigned *mode)\n+{\n+\tchar *prefixpath;\n \tint ret, bracket_depth;\n \tint namelen = strlen(name);\n \tconst char *cp;\n@@ -664,6 +670,9 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \tret = get_sha1_1(name, namelen, sha1);\n \tif (!ret)\n \t\treturn ret;\n+\n+\tprefixpath = prefix ? xmalloc(strlen(prefix) + namelen + 1): NULL;\n+\n \t/* sha1:path --> object name of path in ent sha1\n \t * :path -> object name of path in index\n \t * :[0-3]:path -> object name of path in index at stage\n@@ -685,6 +694,10 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \t\tnamelen = namelen - (cp - name);\n \t\tif (!active_cache)\n \t\t\tread_cache();\n+\t\tif (prefix) {\n+\t\t\tnamelen = sprintf(prefixpath, \"%s%s\", prefix, cp);\n+\t\t\tcp = prefixpath;\n+\t\t}\n \t\tpos = cache_name_pos(cp, namelen);\n \t\tif (pos < 0)\n \t\t\tpos = -pos - 1;\n@@ -696,10 +709,12 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \t\t\tif (ce_stage(ce) == stage) {\n \t\t\t\thashcpy(sha1, ce->sha1);\n \t\t\t\t*mode = ntohl(ce->ce_mode);\n+\t\t\t\tfree(prefixpath);\n \t\t\t\treturn 0;\n \t\t\t}\n \t\t\tpos++;\n \t\t}\n+\t\tfree(prefixpath);\n \t\treturn -1;\n \t}\n \tfor (cp = name, bracket_depth = 0; *cp; cp++) {\n@@ -712,9 +727,15 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \t}\n \tif (*cp == ':') {\n \t\tunsigned char tree_sha1[20];\n-\t\tif (!get_sha1_1(name, cp-name, tree_sha1))\n-\t\t\treturn get_tree_entry(tree_sha1, cp+1, sha1,\n-\t\t\t\t\t mode);\n+\t\tif (!get_sha1_1(name, cp-name, tree_sha1)) {\n+\t\t\tif (!prefix)\n+\t\t\t\tret = get_tree_entry(tree_sha1, cp + 1, sha1, mode);\n+\t\t\telse {\n+\t\t\t\tsprintf(prefixpath, \"%s%s\", prefix, cp + 1);\n+\t\t\t\tret = get_tree_entry(tree_sha1, prefixpath, sha1, mode);\n+\t\t\t\tfree(prefixpath);\n+\t\t\t}\n+\t\t}\n \t}\n \treturn ret;\n }\n-- \n1.5.4.rc0.86.g30f5\n"},{"id":"63672","messageId":"20071218204947.GE2875@steel.home","threadId":"11346","inReplyTo":"20071218204752.GD2875@steel.home","subject":"[PATCH] Introduce pathexpand: syntax-level chdir into the given cwd","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T20:49:47Z","receivedAt":"2007-12-18T20:49:47Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Signed-off-by: Alex Riesen \n---\n\nThis will be used by the following patch. I actually already have sent\nthis one in, as suggestion for some problem back then. It is a bit\ngeneric, so it gets its own patch.\n\n cache.h | 2 ++\n path.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 61 insertions(+), 0 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 054f106..25ce5da 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -383,6 +383,8 @@ static inline int is_absolute_path(const char *path)\n \treturn path[0] == '/';\n }\n const char *make_absolute_path(const char *path);\n+/* Returns the analog of \"cd path\" from a directory \"cwd\" */\n+extern char *pathexpand(const char *cwd, const char *path);\n \n /* Read and unpack a sha1 file into memory, write memory to a sha1 file */\n extern int sha1_object_info(const unsigned char *, unsigned long *);\ndiff --git a/path.c b/path.c\nindex 4260952..8231cd8 100644\n--- a/path.c\n+++ b/path.c\n@@ -353,3 +353,62 @@ const char *make_absolute_path(const char *path)\n \n \treturn buf;\n }\n+\n+/*\n+ * Returns the analog of \"cd path\" from a directory \"cwd\".\n+ * The root is defined as empty path (instead of \"/\")\n+ * An attempt to go past the root (with \"..\") leaves the path at root.\n+ * The cwd is not expanded.\n+ */\n+char *pathexpand(const char *cwd, const char *path)\n+{\n+\tstatic const char SEP[] = \"/\";\n+\tif (!*path) /* empty path -> \".\" (don't move) */\n+\t\tpath = \".\";\n+\tif (!cwd || !*cwd || *SEP == *path) /* no cwd, or path begins with \"/\" */\n+\t\tcwd = \"\";\n+\n+\twhile (*cwd && *SEP == *cwd)\n+\t\t++cwd;\n+\n+\tsize_t len = strlen(cwd);\n+\tchar *out = malloc(len + 1 + strlen(path) + 1);\n+\tchar *p = strcpy(out, cwd) + len;\n+\n+\tfor (; *path; ++path)\n+\t{\n+\t\tchar *pl;\n+\t\tif (p > out && p[-1] != *SEP)\n+\t\t\t*p++ = *SEP;\n+\t\tpl = p;\n+\t\twhile (*path && *SEP != *path)\n+\t\t\t*p++ = *path++;\n+\t\t*p = '\\0';\n+\t\t/* ...\"//\"... */\n+\t\tif (p == pl)\n+\t\t\t; /* just ignore */\n+\t\t/* ...\"/./\"... */\n+\t\telse if ( p - pl == 1 && '.' == *pl )\n+\t\t\t--p; /* just ignore */\n+\t\t/* ...\"/../\"... */\n+\t\telse if ( p - pl == 2 && '.' == pl[0] && '.' == pl[1] )\n+\t\t{\n+\t\t\t/* drop the last element of the resulting path */\n+\t\t\tif (pl > out && --pl > out)\n+\t\t\t\tfor (--pl; pl > out && *SEP != *pl; --pl)\n+\t\t\t\t\t;\n+\t\t\tp = pl > out ? ++pl: out;\n+\t\t}\n+\t\t/* ...\"/path/\"... */\n+\t\telse if (*path)\n+\t\t\t*p++ = *path; /* just add the separator */\n+\n+\t\tif (!*path)\n+\t\t\tbreak;\n+\t}\n+\tif (p > out+1 && *SEP == p[-1])\n+\t\t--p;\n+\t*p = '\\0';\n+\treturn out;\n+}\n+\n-- \n1.5.4.rc0.86.g30f5\n"},{"id":"63673","messageId":"20071218205253.GF2875@steel.home","threadId":"11346","inReplyTo":"20071218204947.GE2875@steel.home","subject":"[PATCH] Use pathexpand to preparse the relative pathnames in blob references","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T20:52:53Z","receivedAt":"2007-12-18T20:52:53Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Signed-off-by: Alex Riesen \n---\n\nThis, OTOH, is a bit intrusive and changes the current behaviour a bit\ntoo far. git-show cannot use the absolute pathnames in blob locators\nat all now, which I consider bad. An obvious way to use rev:/path is\nblocked by Johannes' get_sha1_oneline. It would have worked, though.\n\n sha1_name.c | 21 +++++++--------------\n 1 files changed, 7 insertions(+), 14 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 358aab7..369e7d0 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -661,7 +661,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \n int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sha1, unsigned *mode)\n {\n-\tchar *prefixpath;\n+\tchar *prefixpath = NULL;\n \tint ret, bracket_depth;\n \tint namelen = strlen(name);\n \tconst char *cp;\n@@ -671,8 +671,6 @@ int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sh\n \tif (!ret)\n \t\treturn ret;\n \n-\tprefixpath = prefix ? xmalloc(strlen(prefix) + namelen + 1): NULL;\n-\n \t/* sha1:path --> object name of path in ent sha1\n \t * :path -> object name of path in index\n \t * :[0-3]:path -> object name of path in index at stage\n@@ -694,10 +692,9 @@ int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sh\n \t\tnamelen = namelen - (cp - name);\n \t\tif (!active_cache)\n \t\t\tread_cache();\n-\t\tif (prefix) {\n-\t\t\tnamelen = sprintf(prefixpath, \"%s%s\", prefix, cp);\n-\t\t\tcp = prefixpath;\n-\t\t}\n+\t\tprefixpath = pathexpand(prefix, cp);\n+\t\tnamelen = strlen(prefixpath);\n+\t\tcp = prefixpath;\n \t\tpos = cache_name_pos(cp, namelen);\n \t\tif (pos < 0)\n \t\t\tpos = -pos - 1;\n@@ -728,13 +725,9 @@ int get_sha1_with_prefix(const char *prefix, const char *name, unsigned char *sh\n \tif (*cp == ':') {\n \t\tunsigned char tree_sha1[20];\n \t\tif (!get_sha1_1(name, cp-name, tree_sha1)) {\n-\t\t\tif (!prefix)\n-\t\t\t\tret = get_tree_entry(tree_sha1, cp + 1, sha1, mode);\n-\t\t\telse {\n-\t\t\t\tsprintf(prefixpath, \"%s%s\", prefix, cp + 1);\n-\t\t\t\tret = get_tree_entry(tree_sha1, prefixpath, sha1, mode);\n-\t\t\t\tfree(prefixpath);\n-\t\t\t}\n+\t\t\tprefixpath = pathexpand(prefix, cp + 1);\n+\t\t\tret = get_tree_entry(tree_sha1, prefixpath, sha1, mode);\n+\t\t\tfree(prefixpath);\n \t\t}\n \t}\n \treturn ret;\n-- \n1.5.4.rc0.86.g30f5\n"},{"id":"63674","messageId":"56b7f5510712181303h1e7ae35dpa0adfd6804a7cecd@mail.gmail.com","threadId":"11346","inReplyTo":"20071218204752.GD2875@steel.home","subject":"Re: [PATCH] Simple support for tree entry specification with relative pathnames","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-18T21:03:04Z","receivedAt":"2007-12-18T21:03:04Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"ACK from me...\n\nI submitted a similar patch last May 4 which also\nchanged sha1_name.c to do this. The patch\nadded a config variable to control this\n(probably not desirable). The patch also handled\nleading/embedded . and .. .\n\nIn p4 you can say\n p4 file#rev\nand file is interpreted relatively.\n\nI wanted to be able to say\n git tree:file\nand have file interpreted relatively.\nThis should only happen when you are inside the work tree.\n\nGood luck!\n\nDana\n\nOn Dec 18, 2007 12:47 PM, Alex Riesen wrote:\n> This allows git show to understand something like this:\n>\n> $ test -f DIR/file && cd DIR && git show rev:file\n>\n> Signed-off-by: Alex Riesen \n> ---\n>\n> This is a bit too simplistic and can be fooled easily:\n>\n> .../t$ git show HEAD:../t/test-lib.sh\n>\n> wont work. It is short, though.\n\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63675","messageId":"56b7f5510712181306k13e8b06dt35313e09727a8f59@mail.gmail.com","threadId":"11346","inReplyTo":"20071218205253.GF2875@steel.home","subject":"Re: [PATCH] Use pathexpand to preparse the relative pathnames in blob references","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-18T21:06:38Z","receivedAt":"2007-12-18T21:06:38Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 18, 2007 12:52 PM, Alex Riesen wrote:\n> This, OTOH, is a bit intrusive and changes the current behaviour a bit\n> too far. git-show cannot use the absolute pathnames in blob locators\n> at all now, which I consider bad. An obvious way to use rev:/path is\n> blocked by Johannes' get_sha1_oneline. It would have worked, though.\n\nLast May Junio proposed the current :/ should be changed to :?\nsince it actually searches backwards. Then :/ would be an absolute path,\nand : could default to relative (like Unix command line).\n\nBecause of this incompatibility I think he wanted to delay it\nuntil 1.5.6 or 1.6 (see old thread).\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63677","messageId":"20071218211713.GG2875@steel.home","threadId":"11346","inReplyTo":"56b7f5510712181303h1e7ae35dpa0adfd6804a7cecd@mail.gmail.com","subject":"Re: [PATCH] Simple support for tree entry specification with relative pathnames","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T21:17:13Z","receivedAt":"2007-12-18T21:17:13Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dana How, Tue, Dec 18, 2007 22:03:04 +0100:\n> ACK from me...\n\nBut NAK from me. Definitely not in this form. Please consider the\npatches *only* as an RFC.\n\n> I submitted a similar patch last May 4 which also changed\n> sha1_name.c to do this. The patch added a config variable to\n> control this (probably not desirable). The patch also handled\n> leading/embedded . and .. .\n\nThis one (the last in series) too.\n\n> In p4 you can say\n> p4 file#rev\n> and file is interpreted relatively.\n> \n> I wanted to be able to say\n> git tree:file\n> and have file interpreted relatively.\n> This should only happen when you are inside the work tree.\n\nIt is pure coincedence the syntaxes look similar. They are very deeply\ndifferent in Git and Perforce.\n"},{"id":"63679","messageId":"200712182224.28152.jnareb@gmail.com","threadId":"11346","inReplyTo":"20071218204623.GC2875@steel.home","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-18T21:24:26Z","receivedAt":"2007-12-18T21:24:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 18 Dec 2007, Alex Riesen wrote:\n> Jakub Narebski, Tue, Dec 18, 2007 18:50:20 +0100:\n>> Alex Riesen writes:\n>> \n>>> Noticed by a collegue of mine. Consider:\n>>> \n>>> $ cd $GIT/t\n>>> $ git show 570f32266:t/test-lib.sh # works\n>>> $ git show 570f32266:test-lib.sh # does not work\n>>> $ git show 570f32266:./test-lib.sh # does not work\n>>> $ git show 570f32266:/t/test-lib.sh # does not work\n>>> \n>>> Considering that the relative path names work as filters (and many\n>>> agreed on that being useful), it would be nice to allow relative\n>>> pathnames in blob specifications for git-show and git-cat-file.\n>>> \n>>> (besides the colon is a good delimiter, even tab-completion\n>>> works with it) \n>> \n>> If you think about it a bit, relative path names nor absolute\n>> path names does and should not work. 570f32266:t/test-lib.sh\n>> means path t/test-lib.sh staring from 570f32266^{tree}. Where\n>> you are in the filesystem is not important and matters not for\n>> this syntax. Besides if you access other branch file might be\n>> not in filesystem (deleted file, or disjoint branch with separate\n>> contents like 'todo' or 'html' branch in git.git repository).\n> \n> Not convinced. It is *not* the plumbing problem I was trying to\n> describe. They discussion, metaphorically, should not have left the\n> command-line parser.\n> \n> I think that we have parsing of the blob locators at the wrong level:\n> so that git-show, git-log and git-diff can handle its pathnames as\n> they handle path filters (relative to cwd),\n\nWhat cwd? in : syntax is \"relative\" to .\nIMHO \":\" should be considered (and is considered) as\none object: current working directory doesn't matter at all there,\ncontrary to \" -- \" where it is natural that \nis relative to current working directory.\n\nWhat should git do in your proposal when we are on master branch in\nDocumentation subdirectory, and want to check TODO file in todo branch?\n\"git show todo:TODO\" is most natural IMHO.\n\nNote that for true as you just don't know where\nin the working area directory hierarchy can be. This means you\ndo't know relation of and in : to cwd.\n\n> and git-cat-file, \n> git-diff-tree, git-rev-list, etc can handle theirs always relative to\n> the project root.\n\nNot \"relative to project root\". Relative to tree-ish used on right hand\nside in : extended SHA-1 syntax. It is usually project\nroot, because when you specify or as it refers\nto top/root directory of a project.\n\n> I actually do not see any problem for git-show (being porcelain-level\n> program) to treat *each and every* path anywhere relatively to the\n> current directory. It is just more comfortable.\n\nThis breaks backward compatibility, hard. And IMHO breaks layers.\n\nBut if (big if) it was to be implemented, default behavior should be\nunchanged, and relative to the cwd (layers!) should use new syntax,\nfor example\n\n $ cd $GIT/t\n $ git show 570f32266:t/test-lib.sh # works\n $ git show 570f32266:test-lib.sh # should not work\n $ git show 570f32266:./test-lib.sh # should work\n $ git show 570f32266:/t/test-lib.sh # should perhaps work\n \nCurrently \":/\" (but not \":/\") is taken; see\ngit-rev-parse(1), \"Specifying revisions\".\n\n-- \nJakub Narebski\nPoland\n"},{"id":"63684","messageId":"alpine.LFD.0.9999.0712181347140.21557@woody.linux-foundation.org","threadId":"11346","inReplyTo":"200712182224.28152.jnareb@gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-18T21:53:20Z","receivedAt":"2007-12-18T21:53:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Dec 2007, Jakub Narebski wrote:\n> \n> What cwd? in : syntax is \"relative\" to .\n> IMHO \":\" should be considered (and is considered) as\n> one object: current working directory doesn't matter at all there,\n> contrary to \" -- \" where it is natural that \n> is relative to current working directory.\n\nIndeed.\n\nThe : syntax *is* relative, but it's relative to the exact \n*treeish* that is given. It has nothing what-so-ever to do with the \ncurrent working directory, since the user has explicitly given an exact \ntree object, and trying to fake that out would be actively wrong.\n\nThat said, I can kind of understand the wish for something like this, and \nI suspect that we could make the \"commit->tree\" translation take the \ncurrent path into account. In other words, maybe we should have something \nlike this:\n\n\t/*\n\t * This sequence currently works\n\t */\n\t[torvalds@woody git]$ git rev-parse HEAD\n\tf9c5a80cdf2265f2df7712fad9f1fb7ef68b4768\n\n\t[torvalds@woody git]$ git rev-parse HEAD^{tree}\n\t051fb0c0dff4371f97f8ad9407f9f1fd335b1682\n\n\t[torvalds@woody git]$ git rev-parse HEAD^{tree}:t\n\t49d8bcd7a2df5c17193b1d002c4a8489d4fa990c\n\n\t/*\n\t * .. but this would be new\n\t */\n\t[torvalds@woody git]$ cd t\n\t[torvalds@woody t]$ git rev-parse HEAD^{tree}\n\t49d8bcd7a2df5c17193b1d002c4a8489d4fa990c\n\nwhere the magic is *not* done by any \"SHA1 path lookup\" at all, but is \nsimply done by the commit->tree lookup. At least at that point it would \nmake logical sense (although it would probably be quite painful to \nimplement).\n\n\t\t\tLinus\n"},{"id":"63689","messageId":"56b7f5510712181408g4aee55d2j2a7f0f13bf90323d@mail.gmail.com","threadId":"11346","inReplyTo":"alpine.LFD.0.9999.0712181347140.21557@woody.linux-foundation.org","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-18T22:08:33Z","receivedAt":"2007-12-18T22:08:33Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 18, 2007 1:53 PM, Linus Torvalds wrote:\n> On Tue, 18 Dec 2007, Jakub Narebski wrote:\n> >\n> > What cwd? in : syntax is \"relative\" to .\n> > IMHO \":\" should be considered (and is considered) as\n> > one object: current working directory doesn't matter at all there,\n> > contrary to \" -- \" where it is natural that \n> > is relative to current working directory.\n>\n> Indeed.\n>\n> The : syntax *is* relative, but it's relative to the exact\n> *treeish* that is given. It has nothing what-so-ever to do with the\n> current working directory, since the user has explicitly given an exact\n> tree object, and trying to fake that out would be actively wrong.\n\nI think the solution is to use the cwd only when the tree-ish refers\nto a commit.\nIf it refers explicitly to a tree (or to a tree through a tag w/o\ngoing through a commit)\nthen you don't make any modification.\n\nWhen it *does* refer to a commit, then for commit:relpath you prefix\nrelpath with the suffix of the cwd which is an extension beyond the root\nof the working tree.\n\nAt the time I thought this through submodules didn't exist.\nClearly that case needs to be thought through as well.\n\n> That said, I can kind of understand the wish for something like this, and\n> I suspect that we could make the \"commit->tree\" translation take the\n> current path into account. In other words, maybe we should have something\n> like this:\n>\n> /*\n> * This sequence currently works\n> */\n> [torvalds@woody git]$ git rev-parse HEAD\n> f9c5a80cdf2265f2df7712fad9f1fb7ef68b4768\n>\n> [torvalds@woody git]$ git rev-parse HEAD^{tree}\n> 051fb0c0dff4371f97f8ad9407f9f1fd335b1682\n>\n> [torvalds@woody git]$ git rev-parse HEAD^{tree}:t\n> 49d8bcd7a2df5c17193b1d002c4a8489d4fa990c\n>\n> /*\n> * .. but this would be new\n> */\n> [torvalds@woody git]$ cd t\n> [torvalds@woody t]$ git rev-parse HEAD^{tree}\n> 49d8bcd7a2df5c17193b1d002c4a8489d4fa990c\n>\n> where the magic is *not* done by any \"SHA1 path lookup\" at all, but is\n> simply done by the commit->tree lookup. At least at that point it would\n> make logical sense (although it would probably be quite painful to\n> implement).\n\nI must be missing something. The old patch I submitted did this.\nIts defect was that it did NOT make the cwd insertion conditional\non whether the tree-ish involved a commit or not (a test which also\n_seems_ doable, but I don't think I finished it & sent it in).\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63691","messageId":"7vejdjy79y.fsf@gitster.siamese.dyndns.org","threadId":"11346","inReplyTo":"alpine.LFD.0.9999.0712181347140.21557@woody.linux-foundation.org","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-18T22:20:25Z","receivedAt":"2007-12-18T22:20:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 18 Dec 2007, Jakub Narebski wrote:\n>> \n>> What cwd? in : syntax is \"relative\" to .\n>> IMHO \":\" should be considered (and is considered) as\n>> one object: current working directory doesn't matter at all there,\n>> contrary to \" -- \" where it is natural that \n>> is relative to current working directory.\n>\n> Indeed.\n>\n> The : syntax *is* relative, but it's relative to the exact \n> *treeish* that is given. It has nothing what-so-ever to do with the \n> current working directory, since the user has explicitly given an exact \n> tree object, and trying to fake that out would be actively wrong.\n>\n> That said, I can kind of understand the wish for something like this, and \n> I suspect that we could make the \"commit->tree\" translation take the \n> current path into account. In other words, maybe we should have something \n> like this:\n>\n> \t/*\n> \t * This sequence currently works\n> \t */\n> \t[torvalds@woody git]$ git rev-parse HEAD\n> \tf9c5a80cdf2265f2df7712fad9f1fb7ef68b4768\n>\n> \t[torvalds@woody git]$ git rev-parse HEAD^{tree}\n> \t051fb0c0dff4371f97f8ad9407f9f1fd335b1682\n>\n> \t[torvalds@woody git]$ git rev-parse HEAD^{tree}:t\n> \t49d8bcd7a2df5c17193b1d002c4a8489d4fa990c\n>\n> \t/*\n> \t * .. but this would be new\n> \t */\n> \t[torvalds@woody git]$ cd t\n> \t[torvalds@woody t]$ git rev-parse HEAD^{tree}\n> \t49d8bcd7a2df5c17193b1d002c4a8489d4fa990c\n>\n> where the magic is *not* done by any \"SHA1 path lookup\" at all, but is \n> simply done by the commit->tree lookup. At least at that point it would \n> make logical sense (although it would probably be quite painful to \n> implement).\n\nIt is not just painful to implement.\n\nAlthough I can buy that purely from the user (read: people who do not\nknow how the world works) experience point of view, you have to be extra\ncareful if you do this. There are existing codepaths that take a string\nthat names a treeish from the end user, appends \"^{tree}\" to that\nstring, and passes the result to get_sha1() to obtain a tree object name\nthey want to operate on (the alternative is parse_tree_indirect() but it\nforces them to go through the object layer). You will need to update\nthese callers to keep them working from subdirectories.\n"},{"id":"63692","messageId":"20071218222032.GH2875@steel.home","threadId":"11346","inReplyTo":"200712182224.28152.jnareb@gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T22:20:32Z","receivedAt":"2007-12-18T22:20:32Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:\n> On Tue, 18 Dec 2007, Alex Riesen wrote:\n> > I think that we have parsing of the blob locators at the wrong level:\n> > so that git-show, git-log and git-diff can handle its pathnames as\n> > they handle path filters (relative to cwd),\n> \n> What cwd? in : syntax is \"relative\" to .\n\nBut the act of running \"git-show :\" does have a\nworking directory relative to the project root. And usually the\nrelative directory makes a lot of sense in git-show commands.\n\n> What should git do in your proposal when we are on master branch in\n> Documentation subdirectory, and want to check TODO file in todo branch?\n> \"git show todo:TODO\" is most natural IMHO.\n\nYes, and that's why I NAKed the patches in the mail to Dana. I just\nhope the problem gets some attention. Maybe I even get something out\nof it, maybe not. It is not that hard to keep the patches in my tree.\n\n> Note that for true as you just don't know where\n> in the working area directory hierarchy can be. This means you\n> do't know relation of and in : to cwd.\n\nI understand. But... How often do you think people use git show with a\ntree which was not pointed by a commit?\n\n> > and git-cat-file, \n> > git-diff-tree, git-rev-list, etc can handle theirs always relative to\n> > the project root.\n> \n> Not \"relative to project root\". Relative to tree-ish used on right hand\n> side in : extended SHA-1 syntax. It is usually project\n> root, because when you specify or as it refers\n> to top/root directory of a project.\n\nI know. My problem: it is also awkward. git-show :test-lib.sh just\ndoes not do what I expect. Nor does git cat-file HEAD:test-lib.sh.\nAnd git cat-file HEAD:t/test-l does not work at all. And this is\nvery simple example. Normally the pathnames are about 100 characters\nlong.\n\nYou know, it maybe as much correct as you wish, but is not very\nusable (and no, I can't use the contributed completion. For lots of\nreasons).\n\n> > I actually do not see any problem for git-show (being porcelain-level\n> > program) to treat *each and every* path anywhere relatively to the\n> > current directory. It is just more comfortable.\n> \n> This breaks backward compatibility, hard. And IMHO breaks layers.\n\nMaybe they should be broken in porcelain...\n\n> But if (big if) it was to be implemented, default behavior should be\n> unchanged, and relative to the cwd (layers!) should use new syntax,\n> for example\n> \n> $ cd $GIT/t\n> $ git show 570f32266:t/test-lib.sh # works\n> $ git show 570f32266:test-lib.sh # should not work\n\nWell... Frankly, I suggest changing this for porcelain-level\ncommands (show and diff) and leave it as it is for plumbing.\n\n> $ git show 570f32266:./test-lib.sh # should work\n\nDefinitely. I even implemented a patch to allow just this, but scraped\nit: it looked a bit small and the syntax is not obvious to the user.\nMaybe that is what I end up with, though.\n\n> $ git show 570f32266:/t/test-lib.sh # should perhaps work\n> Currently \":/\" (but not \":/\") is taken; see\n\nYes, and it becomes more and more an obstacle. With just one user\nstanding, AFAICS (/me considers Dscho's assassination for moment...\nNah... Maybe poison?)\n"},{"id":"63696","messageId":"20071218222955.GI2875@steel.home","threadId":"11346","inReplyTo":"56b7f5510712181408g4aee55d2j2a7f0f13bf90323d@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-18T22:29:55Z","receivedAt":"2007-12-18T22:29:55Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dana How, Tue, Dec 18, 2007 23:08:33 +0100:\n> When it *does* refer to a commit, then for commit:relpath you prefix\n> relpath with the suffix of the cwd which is an extension beyond the root\n> of the working tree.\n\n...universally known as \"prefix\" (the last argument of builtin\ncommands) :)\n\n> > where the magic is *not* done by any \"SHA1 path lookup\" at all, but is\n> > simply done by the commit->tree lookup. At least at that point it would\n> > make logical sense (although it would probably be quite painful to\n> > implement).\n> \n> I must be missing something. The old patch I submitted did this.\n> Its defect was that it did NOT make the cwd insertion conditional\n> on whether the tree-ish involved a commit or not (a test which also\n> _seems_ doable, but I don't think I finished it & sent it in).\n\nIt is also a bit painful: lots of funtions (sha1_name.c) will have\ntheir prototypes changed to get the prefix (aka suffix). And their\ncallers...\n"},{"id":"63697","messageId":"56b7f5510712181430w798d4a65x20a24f061c5d0eb6@mail.gmail.com","threadId":"11346","inReplyTo":"7vejdjy79y.fsf@gitster.siamese.dyndns.org","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-18T22:30:40Z","receivedAt":"2007-12-18T22:30:40Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 18, 2007 2:20 PM, Junio C Hamano wrote:\n> Linus Torvalds writes:\n> > where the magic is *not* done by any \"SHA1 path lookup\" at all, but is\n> > simply done by the commit->tree lookup. At least at that point it would\n> > make logical sense (although it would probably be quite painful to\n> > implement).\n>\n> It is not just painful to implement.\n>\n> Although I can buy that purely from the user (read: people who do not\n> know how the world works) experience point of view, you have to be extra\n> careful if you do this. There are existing codepaths that take a string\n> that names a treeish from the end user, appends \"^{tree}\" to that\n> string, and passes the result to get_sha1() to obtain a tree object name\n> they want to operate on (the alternative is parse_tree_indirect() but it\n> forces them to go through the object layer). You will need to update\n> these callers to keep them working from subdirectories.\n\nThanks, I didn't know about those \"^{tree}\" codepaths.\n\nHow about this:\n:./path -> NEW: relative\n:../path -> NEW: relative\n:?pattern -> NEW: same as next (current :/ )\n:/pattern -> unchanged (sha1_name_oneline IIRC)\n:path -> unchanged: absolute\nThis shouldn't need to know if tree-ish references a commit or not.\n\nSomeday later, the last 2 cases could be changed to be more\nlike the Unix command line if desired. This is very similar to\nJunio's response last May (by memory).\n\nTyping an extra \"./\" is a big improvement over a long path prefix.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63698","messageId":"Pine.LNX.4.64.0712182239500.23902@racer.site","threadId":"11346","inReplyTo":"20071218222032.GH2875@steel.home","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-18T22:43:52Z","receivedAt":"2007-12-18T22:43:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Dec 2007, Alex Riesen wrote:\n\n> Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:\n> > On Tue, 18 Dec 2007, Alex Riesen wrote:\n> >\n> > > I think that we have parsing of the blob locators at the wrong \n> > > level: so that git-show, git-log and git-diff can handle its \n> > > pathnames as they handle path filters (relative to cwd),\n> > \n> > What cwd? in : syntax is \"relative\" to \n> > .\n> \n> But the act of running \"git-show :\" does have a working \n> directory relative to the project root.\n\nNot necessarily. My primary use of \"git show :\" (yes, I \nalready use the dash-less form ;-) is in _bare_ repositories.\n\nAnd I still maintain that expecting : to take the current \nrelative path into account would be just like if you expected\n\n\tC:\\> cd WINDOWS\n\tC:\\WINDOWS> dir D:system32\n\nto show you the contents of D:\\WINDOWS\\system32.\n\nOr another, less Windowsy example:\n\n\t$ cd /usr/bin\n\t$ scp home:bash ./\n\nNo, this does not copy home:/usr/bin/bash but home:$HOME/bash.\n\nHth,\nDscho\n"},{"id":"63700","messageId":"Pine.LNX.4.64.0712182250040.23902@racer.site","threadId":"11346","inReplyTo":"56b7f5510712181430w798d4a65x20a24f061c5d0eb6@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-18T23:02:42Z","receivedAt":"2007-12-18T23:02:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Dec 2007, Dana How wrote:\n\n> [lots about rev:path taking path to be relative to the project root, \n> preferring it to be relative to the current prefix instead]\n> \n> Typing an extra \"./\" is a big improvement over a long path prefix.\n\nHave you tried the path completion?\n\nAlternatively, I suggest making a script\n\n\t$ cat > $HOME/bin/git-showrel << \\EOF\n\t#!/bin/sh\n\tgit show \"$(echo \"$1\" | sed \"s|:|:$(git rev-parse --show-prefix)|\")\"\n\tEOF\n\t$ chmod a+x $HOME/bin/git-showrel\n\nThen\n\n\t$ git showrel HEAD:file\n\nwill do what you want.\n\n(An alias will not work, since the cwd will be the project root.)\n\nHth,\nDscho\n\nP.S.: I just tried \"git show HEAD~20:\" and it did \nnot work... I consider this a more serious issue than the relative path \none.\n"},{"id":"63701","messageId":"56b7f5510712181503l1e5dcacds23511d968f98aedb@mail.gmail.com","threadId":"11346","inReplyTo":"Pine.LNX.4.64.0712182239500.23902@racer.site","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-18T23:03:32Z","receivedAt":"2007-12-18T23:03:32Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 18, 2007 2:43 PM, Johannes Schindelin wrote:\n> On Tue, 18 Dec 2007, Alex Riesen wrote:\n> > But the act of running \"git-show :\" does have a working\n> > directory relative to the project root.\n>\n> Not necessarily. My primary use of \"git show :\" (yes, I\n> already use the dash-less form ;-) is in _bare_ repositories.\n>\n> And I still maintain that expecting : to take the current\n> relative path into account would be just like if you expected\n>\n> C:\\> cd WINDOWS\n> C:\\WINDOWS> dir D:system32\n>\n> to show you the contents of D:\\WINDOWS\\system32.\n>\n> Or another, less Windowsy example:\n>\n> $ cd /usr/bin\n> $ scp home:bash ./\n>\n> No, this does not copy home:/usr/bin/bash but home:$HOME/bash.\n\nBoth of your counterexamples use 2 disjoint directory trees:\nC: vs D:, or trees on different machines.\n\nThe cases we are talking about are all subtrees of the working tree.\nThere is a useful cwd suffix.\n\nDon't you think that\n git commit:./file.c\ncould occasionally be more convenient than\n git commit:very/long/and/boring/path/equal/to/cwd/file.c\n?\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63702","messageId":"200712190005.27154.jnareb@gmail.com","threadId":"11346","inReplyTo":"20071218222032.GH2875@steel.home","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-18T23:05:26Z","receivedAt":"2007-12-18T23:05:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 18. grudnia 2007 23:20, Alex Riesen napisał:\n> Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:\n\n>> Not \"relative to project root\". Relative to tree-ish used on right hand\n>> side in : extended SHA-1 syntax. It is usually project\n>> root, because when you specify or as it refers\n>> to top/root directory of a project.\n> \n> I know. My problem: it is also awkward. git-show :test-lib.sh just\n> does not do what I expect. Nor does git cat-file HEAD:test-lib.sh.\n> And git cat-file HEAD:t/test-l does not work at all. And this is\n> very simple example. Normally the pathnames are about 100 characters\n> long.\n\nDoesn't bash completion (or zsh compltion) for git implement this?\nLet me check... it does\n\n $ . contrib/completion/git-completion.bash\n $ git cat-file -p HEAD:t/test-\n $ git cat-file -p HEAD:t/test-lib.sh # autocompleted\n\nIt does work correctly also from within t/ directory.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"63703","messageId":"200712190011.52613.jnareb@gmail.com","threadId":"11346","inReplyTo":"Pine.LNX.4.64.0712182239500.23902@racer.site","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-18T23:11:52Z","receivedAt":"2007-12-18T23:11:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n> On Tue, 18 Dec 2007, Alex Riesen wrote:\n>> Jakub Narebski, Tue, Dec 18, 2007 22:24:26 +0100:\n>>> \n>>> What cwd? in : syntax is \"relative\" to \n>>> .\n>> \n>> But the act of running \"git-show :\" does have a working \n>> directory relative to the project root.\n> \n> Not necessarily. My primary use of \"git show :\" (yes, I \n> already use the dash-less form ;-) is in _bare_ repositories.\n> \n> And I still maintain that expecting : to take the current \n> relative path into account would be just like if you expected\n[...]\n\n> \t$ cd /usr/bin\n> \t$ scp home:bash ./\n> \n> No, this does not copy home:/usr/bin/bash but home:$HOME/bash.\n\nGreat example! In scp :, by default is relative\nto the login (ssh) directory on . In git's :,\n by default is relative to .\n\nAlthough Linus argument about thinking that cwd affects translation\nfrom _commit_ sha1 to _tree-ish_ is also sound. Nevertheless I'd rather\nhave separate syntax for cwd-relative paths, i.e. :./.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"63704","messageId":"56b7f5510712181515m2b9056b6u70e586358be6f2a1@mail.gmail.com","threadId":"11346","inReplyTo":"200712190011.52613.jnareb@gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-18T23:15:54Z","receivedAt":"2007-12-18T23:15:54Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 18, 2007 3:11 PM, Jakub Narebski wrote:\n> Although Linus argument about thinking that cwd affects translation\n> from _commit_ sha1 to _tree-ish_ is also sound. Nevertheless I'd rather\n> have separate syntax for cwd-relative paths, i.e. :./.\n\nCool -- so adding recognition for \":.\" will support relative paths\nwhen useful and will not interfere with any current syntax.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63705","messageId":"7vzlw7wq05.fsf@gitster.siamese.dyndns.org","threadId":"11346","inReplyTo":"Pine.LNX.4.64.0712182239500.23902@racer.site","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-18T23:18:50Z","receivedAt":"2007-12-18T23:18:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> And I still maintain that expecting : to take the current \n> relative path into account would be just like if you expected\n>\n> \tC:\\> cd WINDOWS\n> \tC:\\WINDOWS> dir D:system32\n>\n> to show you the contents of D:\\WINDOWS\\system32.\n>\n> Or another, less Windowsy example:\n>\n> \t$ cd /usr/bin\n> \t$ scp home:bash ./\n>\n> No, this does not copy home:/usr/bin/bash but home:$HOME/bash.\n\nPlease do not cc me on this topic, unless it is a patch implementing\nsuggestion from Linus to treat $commit^{tree} as relative to $(cwd) but\nfor only when the user directly specified that in full, including ^{tree}\npart.\n"},{"id":"63706","messageId":"Pine.LNX.4.64.0712182323400.23902@racer.site","threadId":"11346","inReplyTo":"56b7f5510712181503l1e5dcacds23511d968f98aedb@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-18T23:26:21Z","receivedAt":"2007-12-18T23:26:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Dec 2007, Dana How wrote:\n\n> On Dec 18, 2007 2:43 PM, Johannes Schindelin wrote:\n> > On Tue, 18 Dec 2007, Alex Riesen wrote:\n> > > But the act of running \"git-show :\" does have a working\n> > > directory relative to the project root.\n> >\n> > Not necessarily. My primary use of \"git show :\" (yes, I\n> > already use the dash-less form ;-) is in _bare_ repositories.\n> >\n> > And I still maintain that expecting : to take the current\n> > relative path into account would be just like if you expected\n> >\n> > C:\\> cd WINDOWS\n> > C:\\WINDOWS> dir D:system32\n> >\n> > to show you the contents of D:\\WINDOWS\\system32.\n> >\n> > Or another, less Windowsy example:\n> >\n> > $ cd /usr/bin\n> > $ scp home:bash ./\n> >\n> > No, this does not copy home:/usr/bin/bash but home:$HOME/bash.\n> \n> Both of your counterexamples use 2 disjoint directory trees:\n> C: vs D:, or trees on different machines.\n\nWell, the first actually only uses 1 \"disjoint\" directory tree. You did \nnot address the concern of the bare repository.\n\n> The cases we are talking about are all subtrees of the working tree. \n> There is a useful cwd suffix.\n\nNot necessarily. You can be in a subdirectory that was not even created \nin _any_ revision. Or you can access a different branch with a different \nhistory.\n\nIt boils down to this: if you need relative paths _only_, you narrowed \nyourself very much in your use cases.\n\n> Don't you think that\n> git commit:./file.c\n> could occasionally be more convenient than\n> git commit:very/long/and/boring/path/equal/to/cwd/file.c\n> ?\n\nActually, it depends on the . And guess what, for those operations \nthat I would like to have that, it already works! \"grep\", \"diff\", \"log\".\n\nCiao,\nDscho\n"},{"id":"63712","messageId":"alpine.LFD.0.9999.0712181711100.21557@woody.linux-foundation.org","threadId":"11346","inReplyTo":"56b7f5510712181503l1e5dcacds23511d968f98aedb@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-19T01:16:14Z","receivedAt":"2007-12-19T01:16:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 18 Dec 2007, Dana How wrote:\n> \n> Both of your counterexamples use 2 disjoint directory trees:\n> C: vs D:, or trees on different machines.\n> \n> The cases we are talking about are all subtrees of the working tree.\n> There is a useful cwd suffix.\n\nNo.\n\nThe cases we're talking of are *not* subtrees of the working tree.\n\nThe SHA1 of a commit may well be a totally disjoint tree. Try it in the \ngit repository with something like\n\n\tgit show origin/man:man1/git-fsck.1\n\nor\n\n\tgit show origin/todo:TODO\n\nand realize that Dscho's examples of using the DOS/Windows drive letters \nis actually a really good example of what that : syntax \nis. \n\nIn fact, you can very well think of the commit/tree as a \"drive letter\". \nIt really does go into another namespace entirely. It's just that often \nthat namespace does bear some relationship to the currently checked out \nbranch. But that's just an \"often\", it's not at all a given.\n\n> Don't you think that\n> git commit:./file.c\n> could occasionally be more convenient than\n> git commit:very/long/and/boring/path/equal/to/cwd/file.c\n\nIt's not about \"convenience\". It's about *sanity* and good design. And the \nfact is, that \"commit:path\" format really has nothing to do with the CWD \nin the general case.\n\n\t\tLinus\n"},{"id":"63713","messageId":"56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com","threadId":"11346","inReplyTo":"alpine.LFD.0.9999.0712181711100.21557@woody.linux-foundation.org","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-19T01:52:23Z","receivedAt":"2007-12-19T01:52:23Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 18, 2007 5:16 PM, Linus Torvalds wrote:\n> On Tue, 18 Dec 2007, Dana How wrote:\n> > The cases we are talking about are all subtrees of the working tree.\n> > There is a useful cwd suffix.\n>\n> No.\n>\n> The cases we're talking of are *not* subtrees of the working tree.\n>\n> The SHA1 of a commit may well be a totally disjoint tree. Try it in the\n> git repository with something like\n\nAgreed, but note you wrote *may*.\n\nI'd like to move some stuff currently in a p4 repository into git.\nThe directory structure within the repo is 13 levels deep;\nI didn't design it nor can I change it.\n\nFor the majority of the cases of interest to me git already accepts\nrelative paths. However, one thing people do often in p4 (or any SCM)\nis look at (or compare, etc) specific revisions. Unfortunately, these are\nnot part of branches or commits, they are just file-specific revisions\n(don't get me started on p4 \"branches\"). The equivalent in git is\nto use a commit name (or a tag) and then name the file. The\nbasic commit:file syntax doesn't accept relative paths. I am not\nspecifically hung up on the commit:./path syntax; I just want some\nnotation that will get those 13 directories from $cwd instead of\nmaking me type them again. Yes, sometimes that might not make\nsense to request.\n\nThere was some mention of bash/zsh completions Unfortunately,\nmuch of our CAD environment is not configured in bash/zsh,\nso although I use bash for some scripting,\nit's not the default for command-line, and won't be used by\nothers I need to drag along with me...\n\n> In fact, you can very well think of the commit/tree as a \"drive letter\".\n> It really does go into another namespace entirely. It's just that often\n> that namespace does bear some relationship to the currently checked out\n> branch. But that's just an \"often\", it's not at all a given.\n>\n> > Don't you think that\n> > git commit:./file.c\n> > could occasionally be more convenient than\n> > git commit:very/long/and/boring/path/equal/to/cwd/file.c\n>\n> It's not about \"convenience\". It's about *sanity* and good design. And the\n> fact is, that \"commit:path\" format really has nothing to do with the CWD\n> in the general case.\n\nYes I frequently get to be one of the people here pushing for\n(and sometimes losing the case for) \"good design\".\nBut I will never be able to successfully argue for retyping 13 directories\nalready in the cwd because it's the \"good\" or \"sane\" thing to do.\n\nGiven that the root of the current working tree, the commit, the cwd,\nand the path (suffix) given on the command line are all known precisely,\nit does not seem dangerous to come up with an exact rule to combine them\nwhich is only triggered by some specific syntax.\n\nThis does not need to work in bare repositories.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n\n(Junio removed from cc: at his request)\n"},{"id":"63720","messageId":"20071219073619.GA2957@steel.home","threadId":"11346","inReplyTo":"56b7f5510712181539g27bd4fc9y632ebe74d91b8e82@mail.gmail.com","subject":"Re: [PATCH] Simple support for tree entry specification with relative pathnames","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-19T07:36:19Z","receivedAt":"2007-12-19T07:36:19Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dana How, Wed, Dec 19, 2007 00:39:13 +0100:\n> So has this idea been shut down again?\n\nSo it seems. Definitely not for 1.5.*\n\n> I don't have the time to update my May 4 patch right now,\n> but you are welcome to look at it and see if it has anything useful.\n\nIt is very similar.\n"},{"id":"63721","messageId":"20071219074215.GB2957@steel.home","threadId":"11346","inReplyTo":"56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-19T07:42:15Z","receivedAt":"2007-12-19T07:42:15Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dana How, Wed, Dec 19, 2007 02:52:23 +0100:\n> Given that the root of the current working tree, the commit, the cwd,\n> and the path (suffix) given on the command line are all known precisely,\n> it does not seem dangerous to come up with an exact rule to combine them\n> which is only triggered by some specific syntax.\n> \n> This does not need to work in bare repositories.\n> \n\nAnd it wont in both patches (your and mine): they don't have prefix\n(aka cwd) at all. The bare repos are just no problem, the pathnames\nthere are always project-absolute.\n"},{"id":"63744","messageId":"200712191223.42446.jnareb@gmail.com","threadId":"11346","inReplyTo":"56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-19T11:23:41Z","receivedAt":"2007-12-19T11:23:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 19 Dec 2007, Dana How wrote:\n> On Dec 18, 2007 5:16 PM, Linus Torvalds wrote:\n>> On Tue, 18 Dec 2007, Dana How wrote:\n>>\n>>> The cases we are talking about are all subtrees of the working tree.\n>>> There is a useful cwd suffix.\n>>\n>> No.\n>>\n>> The cases we're talking of are *not* subtrees of the working tree.\n>>\n>> The SHA1 of a commit may well be a totally disjoint tree. Try it in the\n>> git repository with something like\n> \n> Agreed, but note you wrote *may*.\n> \n> I'd like to move some stuff currently in a p4 repository into git.\n> The directory structure within the repo is 13 levels deep;\n> I didn't design it nor can I change it.\n> \n> For the majority of the cases of interest to me git already accepts\n> relative paths. However, one thing people do often in p4 (or any SCM)\n> is look at (or compare, etc) specific revisions. Unfortunately, these are\n> not part of branches or commits, they are just file-specific revisions\n> (don't get me started on p4 \"branches\"). The equivalent in git is\n> to use a commit name (or a tag) and then name the file. The\n> basic commit:file syntax doesn't accept relative paths. I am not\n> specifically hung up on the commit:./path syntax; I just want some\n> notation that will get those 13 directories from $cwd instead of\n> making me type them again. Yes, sometimes that might not make\n> sense to request.\n[...]\n\nI think new feature like this should be postponed after 1.5.4 is out;\nwe are now in feature freeze (only bugfixes are accepted).\n\nThat said, does git-showrel solution proposed by Johannes Schindelin\nin\n Message-ID: \n http://permalink.gmane.org/gmane.comp.version-control.git/68840\nwork for you?\n\nBelow version of git-showrel script which uses proposed 'commit:./relpath'\nsyntax (it could be improved, of course):\n\ncat > git-showrel <<\\EOF\n#!/bin/sh\n\nrel=$(git rev-parse --show-prefix 2>/dev/null)\ngit show $(echo \"$@\" | sed -e \"s!:./!:${rel}!\")\n\nEOF\n-- \nJakub Narebski\nPoland\n"},{"id":"63765","messageId":"Pine.LNX.4.64.0712191334460.23902@racer.site","threadId":"11346","inReplyTo":"56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com","subject":"[PATCH v0] sha1_name: grok :./","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-19T13:40:27Z","receivedAt":"2007-12-19T13:40:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen you are in a deeply-nested directory structure, and just want\nto reference a blob in a past revision, it can be pretty slow to\ntype out \"HEAD~29:/bla/blub/.../that-file\".\n\nThis patch makes \"HEAD~29:./that-file\" substitute the current prefix\nfor \"./\". If there is not working directory, the prefix is empty.\n\nNote that this patch does not handle \"../\", and neither do I plan to.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Tue, 18 Dec 2007, Dana How wrote:\n\n\t> On Dec 18, 2007 5:16 PM, Linus Torvalds \n\t>\t\t\t wrote:\n\t> > On Tue, 18 Dec 2007, Dana How wrote:\n\t> >\n\t> > > The cases we are talking about are all subtrees of the \n\t> > > working tree. There is a useful cwd suffix.\n\t> >\n\t> > No.\n\t> >\n\t> > The cases we're talking of are *not* subtrees of the working \n\t> > tree.\n\t> >\n\t> > The SHA1 of a commit may well be a totally disjoint tree. Try \n\t> > it in the git repository with something like\n\t> \n\t> Agreed, but note you wrote *may*.\n\n\tOkay, this is a proposed patch. It leaves the existing \n\t\"HEAD:\" handling alone, and only touches \"HEAD:./\", \n\twhich would have been invalid anyway (except if you hacked your \n\tobjects database to include a tree named \".\").\n\n\tNote: this patch is not meant for application directly. It should \n\tbe split into get_current_prefix() as one patch, and the \n\tsha1_name.c stuff as the second. (Not only to boost my ohloh \n\tstatistics, but because they are logically two separate things.)\n\n\tNote, too: this is a quick and little-bit-dirty patch, not well \n\ttested. Particularly, I was unable to trigger the \"No in \n\t\" error path, so I am not confident that this handling is \n\tcorrect.\n\n\tNote also: in contrast to Alex' approach, this will not only work \n\tfor git-show, but for all callers of get_sha1().\n\n cache.h | 1 +\n setup.c | 16 +++++++++++++---\n sha1_name.c | 17 ++++++++++++++---\n 3 files changed, 28 insertions(+), 6 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 39331c2..83a2c31 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -225,6 +225,7 @@ extern char *get_index_file(void);\n extern char *get_graft_file(void);\n extern int set_git_dir(const char *path);\n extern const char *get_git_work_tree(void);\n+extern const char *get_current_prefix(void);\n \n #define ALTERNATE_DB_ENVIRONMENT \"GIT_ALTERNATE_OBJECT_DIRECTORIES\"\n \ndiff --git a/setup.c b/setup.c\nindex b59dbe7..fb9b680 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -3,6 +3,12 @@\n \n static int inside_git_dir = -1;\n static int inside_work_tree = -1;\n+static const char *current_prefix;\n+\n+const char *get_current_prefix()\n+{\n+\treturn current_prefix;\n+}\n \n const char *prefix_path(const char *prefix, int len, const char *path)\n {\n@@ -267,6 +273,7 @@ const char *setup_git_directory_gently(int *nongit_ok)\n \t\t\t\t/* config may override worktree */\n \t\t\t\tif (check_repository_format_gently(nongit_ok))\n \t\t\t\t\treturn NULL;\n+\t\t\t\tcurrent_prefix = retval;\n \t\t\t\treturn retval;\n \t\t\t}\n \t\t\tif (check_repository_format_gently(nongit_ok))\n@@ -279,7 +286,8 @@ const char *setup_git_directory_gently(int *nongit_ok)\n \t\t\tif (chdir(work_tree_env) < 0)\n \t\t\t\tdie (\"Could not chdir to %s\", work_tree_env);\n \t\t\tstrcat(buffer, \"/\");\n-\t\t\treturn retval;\n+\t\t\tcurrent_prefix = retval;\n+\t\t\treturn current_prefix;\n \t\t}\n \t\tif (nongit_ok) {\n \t\t\t*nongit_ok = 1;\n@@ -339,7 +347,8 @@ const char *setup_git_directory_gently(int *nongit_ok)\n \toffset++;\n \tcwd[len++] = '/';\n \tcwd[len] = 0;\n-\treturn cwd + offset;\n+\tcurrent_prefix = cwd + offset;\n+\treturn current_prefix;\n }\n \n int git_config_perm(const char *var, const char *value)\n@@ -396,7 +405,8 @@ const char *setup_git_directory(void)\n \t\tif (retval && chdir(retval))\n \t\t\tdie (\"Could not jump back into original cwd\");\n \t\trel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());\n-\t\treturn rel && *rel ? strcat(rel, \"/\") : NULL;\n+\t\tcurrent_prefix = rel && *rel ? strcat(rel, \"/\") : NULL;\n+\t\treturn current_prefix;\n \t}\n \n \treturn retval;\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 13e1164..6f61d26 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -712,9 +712,20 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \t}\n \tif (*cp == ':') {\n \t\tunsigned char tree_sha1[20];\n-\t\tif (!get_sha1_1(name, cp-name, tree_sha1))\n-\t\t\treturn get_tree_entry(tree_sha1, cp+1, sha1,\n-\t\t\t\t\t mode);\n+\t\tif (!get_sha1_1(name, cp-name, tree_sha1)) {\n+\t\t\tconst char *prefix;\n+\t\t\tif (!prefixcmp(cp + 1, \"./\") &&\n+\t\t\t\t\t(prefix = get_current_prefix())) {\n+\t\t\t\tunsigned char subtree_sha1[20];\n+\t\t\t\tif (get_tree_entry(tree_sha1, prefix,\n+\t\t\t\t\t\t\tsubtree_sha1, mode))\n+\t\t\t\t\treturn error(\"No '%s' in '%.*s'\",\n+\t\t\t\t\t\t\tprefix, cp-name, name);\n+\t\t\t\tmemcpy(tree_sha1, subtree_sha1, 20);\n+\t\t\t\tcp += 2;\n+\t\t\t}\n+\t\t\treturn get_tree_entry(tree_sha1, cp+1, sha1, mode);\n+\t\t}\n \t}\n \treturn ret;\n }\n-- \n1.5.4.rc0.72.g536e9\n"},{"id":"63771","messageId":"20071219143704.GA13942@coredump.intra.peff.net","threadId":"11346","inReplyTo":"20071218205253.GF2875@steel.home","subject":"Re: [PATCH] Use pathexpand to preparse the relative pathnames in blob references","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-19T14:37:04Z","receivedAt":"2007-12-19T14:37:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 18, 2007 at 09:52:53PM +0100, Alex Riesen wrote:\n\n> This, OTOH, is a bit intrusive and changes the current behaviour a bit\n> too far. git-show cannot use the absolute pathnames in blob locators\n> at all now, which I consider bad. An obvious way to use rev:/path is\n> blocked by Johannes' get_sha1_oneline. It would have worked, though.\n\nIMO, this is backwards. The default should be absolute naming (after\nall, you have already rooted it at a tree by saying HEAD:), and you\nshould treat '.' as a short-hand for \"my current prefix\". IOW, this\nworks as before:\n\n cd t && git show HEAD:t/test-lib.sh\n\nbut this would now work:\n\n cd t && git show HEAD:./test-lib.sh\n\nand of course supporting '..' could be added, as well.\n\nThis works under the assumption that you don't have tree entries of '.'\nor '..'; I don't think the data structure enforces any such assumption,\nbut I doubt you could easily create such a tree without hacking the git\ntools (and you would have to be insane to do so anyway).\n\n-Peff\n\nPS I didn't just think of this...I'm pretty sure this discussion came up\nsometime in the past year and somebody more clever than I thought of it.\n"},{"id":"63774","messageId":"20071219150510.GB13942@coredump.intra.peff.net","threadId":"11346","inReplyTo":"Pine.LNX.4.64.0712191334460.23902@racer.site","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-19T15:05:11Z","receivedAt":"2007-12-19T15:05:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 19, 2007 at 01:40:27PM +0000, Johannes Schindelin wrote:\n\n> When you are in a deeply-nested directory structure, and just want\n> to reference a blob in a past revision, it can be pretty slow to\n> type out \"HEAD~29:/bla/blub/.../that-file\".\n> \n> This patch makes \"HEAD~29:./that-file\" substitute the current prefix\n> for \"./\". If there is not working directory, the prefix is empty.\n> \n> Note that this patch does not handle \"../\", and neither do I plan to.\n\nI think this is definitely the right approach. Here's a (possibly\ninsane) alternative. Revert the change in get_sha1_with_mode and detect\n\"./\" in get_tree_entry:\n\ndiff --git a/tree-walk.c b/tree-walk.c\nindex 8d4b673..fc54354 100644\n--- a/tree-walk.c\n+++ b/tree-walk.c\n@@ -191,6 +191,7 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch\n \tunsigned long size;\n \tstruct tree_desc t;\n \tunsigned char root[20];\n+\tconst char *prefix;\n \n \ttree = read_object_with_reference(tree_sha1, tree_type, &size, root);\n \tif (!tree)\n@@ -202,7 +203,11 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch\n \t}\n \n \tinit_tree_desc(&t, tree, size);\n-\tretval = find_tree_entry(&t, name, sha1, mode);\n+\tif (!prefixcmp(name, \"./\") && (prefix = get_current_prefix()))\n+\t\tretval = find_tree_entry(&t, mkpath(\"%s%s\", prefix, name + 2),\n+\t\t\t\tsha1, mode);\n+\telse\n+\t\tretval = find_tree_entry(&t, name, sha1, mode);\n \tfree(tree);\n \treturn retval;\n }\n\n\nThis means that the directory '.' becomes a token replacement for \"my\ncurrent path\" in tree paths. So if you are in \"foo/bar\", and you are\nlooking at a distance commit where the same content was in\n\"baz/foo/bar\", you can do:\n\n git show distant:baz/./file\n\nThis is probably insane because:\n - this is a fairly unlikely use case\n - get_tree_entry gets called in a lot of places, and I have no idea if\n there will be some crazy fallouts.\n\nSo it is probably not worth pursuing, but maybe somebody else can think\nof a good use.\n\n-Peff\n"},{"id":"63783","messageId":"56b7f5510712190921v4350384fx97ab4b89e481ed46@mail.gmail.com","threadId":"11346","inReplyTo":"200712191223.42446.jnareb@gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-19T17:21:44Z","receivedAt":"2007-12-19T17:21:44Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 19, 2007 3:23 AM, Jakub Narebski wrote:\n> On Wed, 19 Dec 2007, Dana How wrote:\n> > I'd like to move some stuff currently in a p4 repository into git.\n> > The directory structure within the repo is 13 levels deep;\n> > I didn't design it nor can I change it.\n> >\n> > ... The\n> > basic commit:file syntax doesn't accept relative paths. I am not\n> > specifically hung up on the commit:./path syntax; I just want some\n> > notation that will get those 13 directories from $cwd instead of\n> > making me type them again.\n>\n> I think new feature like this should be postponed after 1.5.4 is out;\n> we are now in feature freeze (only bugfixes are accepted).\nOK. This is all the conversation that resulted from Alex's RFC.\n\n> That said, does git-showrel solution proposed by Johannes Schindelin\n> in\n> Message-ID: \n> http://permalink.gmane.org/gmane.comp.version-control.git/68840\n> work for you?\n>\n> Below version of git-showrel script which uses proposed 'commit:./relpath'\n> syntax (it could be improved, of course):\n>\n> cat > git-showrel <<\\EOF\n> #!/bin/sh\n>\n> rel=$(git rev-parse --show-prefix 2>/dev/null)\n> git show $(echo \"$@\" | sed -e \"s!:./!:${rel}!\")\n>\n> EOF\n\nIt's definitely true I could use this for now. In the long run\n(meaning after the feature freeze) I don't view this as adequate\nfor 2 reasons:\n(1) I would like a consistent interpretation of commit:path\nwherever it is accepted; and\n(2) If a novice types bad arguments to git-showrel , they\nare probably going to be very confused by its error messages\nwhich are a response to a munged version of their command line.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63784","messageId":"56b7f5510712190940g2a377f4tfe3ca897561ed446@mail.gmail.com","threadId":"11346","inReplyTo":"20071219150510.GB13942@coredump.intra.peff.net","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-12-19T17:40:04Z","receivedAt":"2007-12-19T17:40:04Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Dec 19, 2007 7:05 AM, Jeff King wrote:\n> On Wed, Dec 19, 2007 at 01:40:27PM +0000, Johannes Schindelin wrote:\n> > When you are in a deeply-nested directory structure, and just want\n> > to reference a blob in a past revision, it can be pretty slow to\n> > type out \"HEAD~29:/bla/blub/.../that-file\".\n> >\n> > This patch makes \"HEAD~29:./that-file\" substitute the current prefix\n> > for \"./\". If there is not working directory, the prefix is empty.\n>\n> I think this is definitely the right approach. Here's a (possibly\n> insane) alternative. Revert the change in get_sha1_with_mode and detect\n> \"./\" in get_tree_entry:\n>\n> [..]\n>\n> This means that the directory '.' becomes a token replacement for \"my\n> current path\" in tree paths. So if you are in \"foo/bar\", and you are\n> looking at a distance commit where the same content was in\n> \"baz/foo/bar\", you can do:\n>\n> git show distant:baz/./file\n>\n> This is probably insane because:\n> - this is a fairly unlikely use case\n> - get_tree_entry gets called in a lot of places, and I have no idea if\n> there will be some crazy fallouts.\n>\n> So it is probably not worth pursuing, but maybe somebody else can think\n> of a good use.\n\nFor me, I was only interested in the recognition of ./ at the beginning\nof a path just after : (causing a cwd suffix to be inserted there).\n\nIf there were additional /./ or /../ patterns in the result, I think it\nwould be more useful (e.g. for script writers who forgot to run\ntheir file arguments thru something like \"readlink -f\") for them\nto be squashed out (e.g. in Perl:\n s#/(\\./)+#/#g;\n s#/([^/]*[^./][^/]*/\\.\\./)+#/#g;\n). But this is something that could be added later if desired to\nthe interpretation of all paths, and so seems like a different issue.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"63787","messageId":"20071219180914.GB3015@steel.home","threadId":"11346","inReplyTo":"56b7f5510712190940g2a377f4tfe3ca897561ed446@mail.gmail.com","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-19T18:09:14Z","receivedAt":"2007-12-19T18:09:14Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dana How, Wed, Dec 19, 2007 18:40:04 +0100:\n> If there were additional /./ or /../ patterns in the result, I think it\n> would be more useful (e.g. for script writers who forgot to run\n> their file arguments thru something like \"readlink -f\") for them\n> to be squashed out (e.g. in Perl:\n> s#/(\\./)+#/#g;\n> s#/([^/]*[^./][^/]*/\\.\\./)+#/#g;\n> ). But this is something that could be added later if desired to\n> the interpretation of all paths, and so seems like a different issue.\n\nThis is what the pathexpand in pathexpand-patch does.\n"},{"id":"63790","messageId":"200712191947.05608.jnareb@gmail.com","threadId":"11346","inReplyTo":"56b7f5510712190921v4350384fx97ab4b89e481ed46@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-19T18:47:04Z","receivedAt":"2007-12-19T18:47:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wednesday, 19 December 2007, Dana How wrote:\n> On Dec 19, 2007 3:23 AM, Jakub Narebski wrote:\n>> \n>> That said, does git-showrel solution proposed by Johannes Schindelin\n>> in\n>> Message-ID: \n>> http://permalink.gmane.org/gmane.comp.version-control.git/68840\n>> work for you?\n>>\n>> Below version of git-showrel script which uses proposed\n>> 'commit:./relpath' syntax (it could be improved, of course):\n>>\n>> cat> git-showrel <<\\EOF\n>> #!/bin/sh\n>>\n>> rel=$(git rev-parse --show-prefix 2>/dev/null)\n>> git show $(echo \"$@\" | sed -e \"s!:./!:${rel}!\")\n>>\n>> EOF\n> \n> It's definitely true I could use this for now. In the long run\n> (meaning after the feature freeze) I don't view this as adequate\n> for 2 reasons:\n> (1) I would like a consistent interpretation of commit:path\n> wherever it is accepted; and\n\nOf course this is only interim solution, after 1.5.4 is out, we are out \nof feature freeze, and :./ is in.\n\n> (2) If a novice types bad arguments to git-showrel , they\n> are probably going to be very confused by its error messages\n> which are a response to a munged version of their command line.\n\nActually git-showrel should change only the _last_ argument, passing all \nother unchanged to git-show. But this requires something more than \nsimplest script as above...\n\nUnfortunately my shell script hackery is not up to the task ;-(\n-- \nJakub Narebski\nPoland\n"},{"id":"63796","messageId":"7v8x3qv2g3.fsf@gitster.siamese.dyndns.org","threadId":"11346","inReplyTo":"56b7f5510712181430w798d4a65x20a24f061c5d0eb6@mail.gmail.com","subject":"Re: log/show: relative pathnames do not work in rev:path","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-19T20:45:16Z","receivedAt":"2007-12-19T20:45:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Dana How\" writes:\n\n> How about this:\n> :./path -> NEW: relative\n\nI think making \":./\" mean \"replace ./ with the current prefix and\nretry the usual expansion\" is relatively confusion free. You have to\nwork hard to confuse yourself:\n\n\td=$(git rev-parse --verify HEAD:Documentation)\n git rev-parse \"$d\":./howto ;# would not work\n\tcd Documentation && git rev-parse \"$d\":./howto ;# would work\n\n> :../path -> NEW: relative\n\nI would rather avoid up (../) processing if we can, but making \":\"\nimmediately followed by 1 or more \"../\" mean \"take the current prefix,\nstrip away the same number of trailing directory components as we have\n\"../\" there, and tuck the remainder in front of the path before trying\nthe usual expansion\" would be a natural and relatively confusion free\nextension of the above. I think I can live with that, too.\n\n> :?pattern -> NEW: same as next (current :/ )\n\nI'd prefer keeping :? (or some other unlikely-in-path letter other than\n'?') as a special extension introducer character, i.e. leaving the door\nopen to:\n\n\t:?(magic)parameter\n\nwhose semantics is to be defined later, depending on \"magic\".\n\nSimilarly, we could do the same for\n\n\t:?(magic)parameter\n\n> :/pattern -> unchanged (sha1_name_oneline IIRC)\n\nI do not think this is oneline. \":/pattern\" could be a natural\nextension to the current \":/pattern\" that instructs \"dig from only this\ncommit, not all refs, and find a commit with the oneline,\" but I do not\nthink it is a good idea. It is too similar to \"locate this tree entry\nfrom the given tree\" syntax.\n\n> :path -> unchanged: absolute\n\nAbsolutely ;-)\n"},{"id":"63824","messageId":"7vr6hirx5l.fsf@gitster.siamese.dyndns.org","threadId":"11346","inReplyTo":"Pine.LNX.4.64.0712191334460.23902@racer.site","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-20T01:07:50Z","receivedAt":"2007-12-20T01:07:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> diff --git a/cache.h b/cache.h\n> index 39331c2..83a2c31 100644\n> --- a/cache.h\n> +++ b/cache.h\n> @@ -225,6 +225,7 @@ extern char *get_index_file(void);\n> extern char *get_graft_file(void);\n> extern int set_git_dir(const char *path);\n> extern const char *get_git_work_tree(void);\n> +extern const char *get_current_prefix(void);\n> \n> #define ALTERNATE_DB_ENVIRONMENT \"GIT_ALTERNATE_OBJECT_DIRECTORIES\"\n> \n> diff --git a/setup.c b/setup.c\n> index b59dbe7..fb9b680 100644\n> --- a/setup.c\n> +++ b/setup.c\n> @@ -3,6 +3,12 @@\n> \n> static int inside_git_dir = -1;\n> static int inside_work_tree = -1;\n> +static const char *current_prefix;\n> +\n> +const char *get_current_prefix()\n> +{\n> +\treturn current_prefix;\n> +}\n\nDidn't you just make libification harder?\n"},{"id":"63851","messageId":"Pine.LNX.4.64.0712201145390.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11346","inReplyTo":"7vr6hirx5l.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-20T10:51:50Z","receivedAt":"2007-12-20T10:51:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 19 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > diff --git a/cache.h b/cache.h\n> > index 39331c2..83a2c31 100644\n> > --- a/cache.h\n> > +++ b/cache.h\n> > @@ -225,6 +225,7 @@ extern char *get_index_file(void);\n> > extern char *get_graft_file(void);\n> > extern int set_git_dir(const char *path);\n> > extern const char *get_git_work_tree(void);\n> > +extern const char *get_current_prefix(void);\n> > \n> > #define ALTERNATE_DB_ENVIRONMENT \"GIT_ALTERNATE_OBJECT_DIRECTORIES\"\n> > \n> > diff --git a/setup.c b/setup.c\n> > index b59dbe7..fb9b680 100644\n> > --- a/setup.c\n> > +++ b/setup.c\n> > @@ -3,6 +3,12 @@\n> > \n> > static int inside_git_dir = -1;\n> > static int inside_work_tree = -1;\n> > +static const char *current_prefix;\n> > +\n> > +const char *get_current_prefix()\n> > +{\n> > +\treturn current_prefix;\n> > +}\n> \n> Didn't you just make libification harder?\n\nWell, yes.\n\nActually, no:\n\n\t- I marked this explicitely not ready for application,\n\t- it is not entirely clear if a libgit.a user would not want to \n\t set a default prefix, and\n\t- I decided that I will not be the only one who tries to make \n\t\t libification easy. ;-)\n\nCiao,\nDscho\n"},{"id":"63926","messageId":"fcaeb9bf0712210617x2bafa33cp15815a59fc631f45@mail.gmail.com","threadId":"11346","inReplyTo":"Pine.LNX.4.64.0712191334460.23902@racer.site","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-12-21T14:17:45Z","receivedAt":"2007-12-21T14:17:45Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Dec 19, 2007 8:40 PM, Johannes Schindelin wrote:\n>\n> When you are in a deeply-nested directory structure, and just want\n> to reference a blob in a past revision, it can be pretty slow to\n> type out \"HEAD~29:/bla/blub/.../that-file\".\n>\n> This patch makes \"HEAD~29:./that-file\" substitute the current prefix\n> for \"./\". If there is not working directory, the prefix is empty.\n>\n> Note that this patch does not handle \"../\", and neither do I plan to.\n\nJunio's rc1 announcement got me to read this. It would be indeed\nuseful as I usually work in deep subdirs. However, from my user\nperspective, the right approach is to make :path always be\nrelative to current directory. If you want absolute path, use\n:/path. More intuitive but it breaks current behavior. Can we\nslowly migrate from current absolute-path-by-default behavior to\nrelative-pat- by-default one? (I don't know how to make such migration\nsmoothly though)\n\n> Signed-off-by: Johannes Schindelin \n> ---\n>\n> On Tue, 18 Dec 2007, Dana How wrote:\n>\n> > On Dec 18, 2007 5:16 PM, Linus Torvalds\n> > wrote:\n> > > On Tue, 18 Dec 2007, Dana How wrote:\n> > >\n> > > > The cases we are talking about are all subtrees of the\n> > > > working tree. There is a useful cwd suffix.\n> > >\n> > > No.\n> > >\n> > > The cases we're talking of are *not* subtrees of the working\n> > > tree.\n> > >\n> > > The SHA1 of a commit may well be a totally disjoint tree. Try\n> > > it in the git repository with something like\n> >\n> > Agreed, but note you wrote *may*.\n>\n> Okay, this is a proposed patch. It leaves the existing\n> \"HEAD:\" handling alone, and only touches \"HEAD:./\",\n> which would have been invalid anyway (except if you hacked your\n> objects database to include a tree named \".\").\n>\n> Note: this patch is not meant for application directly. It should\n> be split into get_current_prefix() as one patch, and the\n> sha1_name.c stuff as the second. (Not only to boost my ohloh\n> statistics, but because they are logically two separate things.)\n>\n> Note, too: this is a quick and little-bit-dirty patch, not well\n> tested. Particularly, I was unable to trigger the \"No in\n> \" error path, so I am not confident that this handling is\n> correct.\n>\n> Note also: in contrast to Alex' approach, this will not only work\n> for git-show, but for all callers of get_sha1().\n>\n> cache.h | 1 +\n> setup.c | 16 +++++++++++++---\n> sha1_name.c | 17 ++++++++++++++---\n> 3 files changed, 28 insertions(+), 6 deletions(-)\n>\n> diff --git a/cache.h b/cache.h\n> index 39331c2..83a2c31 100644\n> --- a/cache.h\n> +++ b/cache.h\n> @@ -225,6 +225,7 @@ extern char *get_index_file(void);\n> extern char *get_graft_file(void);\n> extern int set_git_dir(const char *path);\n> extern const char *get_git_work_tree(void);\n> +extern const char *get_current_prefix(void);\n>\n> #define ALTERNATE_DB_ENVIRONMENT \"GIT_ALTERNATE_OBJECT_DIRECTORIES\"\n>\n> diff --git a/setup.c b/setup.c\n> index b59dbe7..fb9b680 100644\n> --- a/setup.c\n> +++ b/setup.c\n> @@ -3,6 +3,12 @@\n>\n> static int inside_git_dir = -1;\n> static int inside_work_tree = -1;\n> +static const char *current_prefix;\n> +\n> +const char *get_current_prefix()\n> +{\n> + return current_prefix;\n> +}\n>\n> const char *prefix_path(const char *prefix, int len, const char *path)\n> {\n> @@ -267,6 +273,7 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> /* config may override worktree */\n> if (check_repository_format_gently(nongit_ok))\n> return NULL;\n> + current_prefix = retval;\n> return retval;\n> }\n> if (check_repository_format_gently(nongit_ok))\n> @@ -279,7 +286,8 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> if (chdir(work_tree_env) < 0)\n> die (\"Could not chdir to %s\", work_tree_env);\n> strcat(buffer, \"/\");\n> - return retval;\n> + current_prefix = retval;\n> + return current_prefix;\n> }\n> if (nongit_ok) {\n> *nongit_ok = 1;\n> @@ -339,7 +347,8 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> offset++;\n> cwd[len++] = '/';\n> cwd[len] = 0;\n> - return cwd + offset;\n> + current_prefix = cwd + offset;\n> + return current_prefix;\n> }\n>\n> int git_config_perm(const char *var, const char *value)\n> @@ -396,7 +405,8 @@ const char *setup_git_directory(void)\n> if (retval && chdir(retval))\n> die (\"Could not jump back into original cwd\");\n> rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());\n> - return rel && *rel ? strcat(rel, \"/\") : NULL;\n> + current_prefix = rel && *rel ? strcat(rel, \"/\") : NULL;\n> + return current_prefix;\n> }\n>\n> return retval;\n> diff --git a/sha1_name.c b/sha1_name.c\n> index 13e1164..6f61d26 100644\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -712,9 +712,20 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n> }\n> if (*cp == ':') {\n> unsigned char tree_sha1[20];\n> - if (!get_sha1_1(name, cp-name, tree_sha1))\n> - return get_tree_entry(tree_sha1, cp+1, sha1,\n> - mode);\n> + if (!get_sha1_1(name, cp-name, tree_sha1)) {\n> + const char *prefix;\n> + if (!prefixcmp(cp + 1, \"./\") &&\n> + (prefix = get_current_prefix())) {\n> + unsigned char subtree_sha1[20];\n> + if (get_tree_entry(tree_sha1, prefix,\n> + subtree_sha1, mode))\n> + return error(\"No '%s' in '%.*s'\",\n> + prefix, cp-name, name);\n> + memcpy(tree_sha1, subtree_sha1, 20);\n> + cp += 2;\n> + }\n> + return get_tree_entry(tree_sha1, cp+1, sha1, mode);\n> + }\n> }\n> return ret;\n> }\n> --\n> 1.5.4.rc0.72.g536e9\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n\n-- \nDuy\n"},{"id":"63940","messageId":"7vbq8k7x91.fsf@gitster.siamese.dyndns.org","threadId":"11346","inReplyTo":"fcaeb9bf0712210617x2bafa33cp15815a59fc631f45@mail.gmail.com","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-21T17:50:34Z","receivedAt":"2007-12-21T17:50:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n>> Note that this patch does not handle \"../\", and neither do I plan to.\n>\n> Junio's rc1 announcement got me to read this. It would be indeed\n> useful as I usually work in deep subdirs. However, from my user\n> perspective, the right approach is to make :path always be\n> relative to current directory. If you want absolute path, use\n> :/path. More intuitive but it breaks current behavior.\n\nI do not know if you followed the discussion thread, but the\n:relative-path has been shown to be broken semantics,\nso even if it may be \"intuitive\", it is intuitive only to people\nwho do not understand the brokenness. Please read the one that\nDscho talks about windows drive letter and Linus agrees that is\na good analogy.\n\nIt might be possible to do :relative and apply that only\nto direct user input, but I do not think it is worth the\ncompatibility and complexity hassle.\n"},{"id":"63949","messageId":"fcaeb9bf0712211215p5d63a434r63340c1f579569bc@mail.gmail.com","threadId":"11346","inReplyTo":"7vbq8k7x91.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-12-21T20:15:28Z","receivedAt":"2007-12-21T20:15:28Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Dec 22, 2007 12:50 AM, Junio C Hamano wrote:\n> \"Nguyen Thai Ngoc Duy\" writes:\n>\n> >> Note that this patch does not handle \"../\", and neither do I plan to.\n> >\n> > Junio's rc1 announcement got me to read this. It would be indeed\n> > useful as I usually work in deep subdirs. However, from my user\n> > perspective, the right approach is to make :path always be\n> > relative to current directory. If you want absolute path, use\n> > :/path. More intuitive but it breaks current behavior.\n>\n> I do not know if you followed the discussion thread, but the\n> :relative-path has been shown to be broken semantics,\n> so even if it may be \"intuitive\", it is intuitive only to people\n> who do not understand the brokenness. Please read the one that\n> Dscho talks about windows drive letter and Linus agrees that is\n> a good analogy.\n>\n> It might be possible to do :relative and apply that only\n> to direct user input, but I do not think it is worth the\n> compatibility and complexity hassle.\n\nArgh! I missed that thread. Will shut up now :-X Thanks for the pointer.\n-- \nDuy\n"},{"id":"63995","messageId":"Pine.LNX.4.64.0712221531110.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11346","inReplyTo":"fcaeb9bf0712210617x2bafa33cp15815a59fc631f45@mail.gmail.com","subject":"Re: [PATCH v0] sha1_name: grok :./","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-22T14:33:14Z","receivedAt":"2007-12-22T14:33:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 21 Dec 2007, Nguyen Thai Ngoc Duy wrote:\n\n> [...] from my user perspective, the right approach is to make \n> :path always be relative to current directory.\n\nAs said by Junio, this would be a bad decision.\n\nBTW please do not quote parts of the email that you do not comment on; it \ntakes half a minute of _everybody_ who tries to read your mail, only to \nrealise that it was time wasted.\n\nCiao,\nDscho\n"}]}