{"thread":{"id":"7979","subject":"[PATCH v3] Support ent:relative_path","startedAt":"2007-05-05T00:47:08Z","lastAt":"2007-05-07T00:37:48Z","messageCount":21,"participants":["Dana How","Jakub Narebski","Johannes Schindelin","Shawn O. Pearce","Junio C Hamano","Alex Riesen","Martin Waitz"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"41107","messageId":"463BD40C.6080909@gmail.com","threadId":"7979","inReplyTo":null,"subject":"[PATCH v3] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-05T00:47:08Z","receivedAt":"2007-05-05T00:47:08Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"\nMost commands accept relative paths, but this is\nnot true of arguments in ent:path format. This\npatch makes all of the following git-show commands\nwork in the git source tree (not just the first):\n % cd xdiff\n % git-show v1.5.2-rc0:xdiff/xemit.h\n % git-show v1.5.2-rc0:./xemit.h\n % git-show v1.5.2-rc0:../sha1_name.c\n\nIt also adds ent:?string as a synonym for ent:/string .\nThis makes the following changes possible later:\nent:/path is an absolute path and ent:path is relative.\n\nSigned-off-by: Dana L. How \n---\n cache.h | 1 +\n setup.c | 5 +++-\n sha1_name.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---\n 3 files changed, 79 insertions(+), 5 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 8e76152..53507d9 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -215,6 +215,7 @@ extern char *get_graft_file(void);\n \n #define ALTERNATE_DB_ENVIRONMENT \"GIT_ALTERNATE_OBJECT_DIRECTORIES\"\n \n+extern const char *prefix_to_cwd;\n extern const char **get_pathspec(const char *prefix, const char **pathspec);\n extern const char *setup_git_directory_gently(int *);\n extern const char *setup_git_directory(void);\ndiff --git a/setup.c b/setup.c\nindex a45ea83..46ae6e3 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -1,5 +1,7 @@\n #include \"cache.h\"\n \n+const char *prefix_to_cwd;\n+\n const char *prefix_path(const char *prefix, int len, const char *path)\n {\n \tconst char *orig = path;\n@@ -252,7 +254,8 @@ const char *setup_git_directory_gently(int *nongit_ok)\n \tcwd[len++] = '/';\n \tcwd[len] = 0;\n \tinside_git_dir = !prefixcmp(cwd + offset, \".git/\");\n-\treturn cwd + offset;\n+\tprefix_to_cwd = cwd + offset;\n+\treturn prefix_to_cwd;\n }\n \n int git_config_perm(const char *var, const char *value)\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 55f25a2..dd415c1 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -593,6 +593,67 @@ static int handle_one_ref(const char *path,\n }\n \n /*\n+ * Future: nonzero to assume relative paths\n+ */\n+#define\tENT_COLON_ASSUME_RELATIVE\t0\n+\n+/*\n+ * Modify path into a full absolute path with no leading \"/\"\n+ * and no \".\" or \"..\". If we can't,\n+ * leave input unaltered for client's error message.\n+ */\n+static void prepend_prefix(const char **cp, int *namelen)\n+{\n+\tchar *t, *t2;\n+\tconst char *cp2 = *cp;\n+\tint type, namelen2 = *namelen;\n+\tstatic char fullpath[PATH_MAX];\n+\tint fixup = strstr(cp2, \"/./\") || strstr(cp2, \"/../\");\n+\tfor (type = 4; --type > 0; )\n+\t\tif (namelen2 > type && !memcmp(cp2, \"../\" + 3 - type, type))\n+\t\t\tbreak;\n+\n+\t/* handle simple cases else create absolute path */\n+\tfullpath[0] = 0;\n+\tif ((type == 0 && !ENT_COLON_ASSUME_RELATIVE) || type == 1) {\n+\t\tif (!fixup) goto done;\n+\t} else\n+\tif (prefix_to_cwd) {\n+\t\tnamelen2 += strlen(prefix_to_cwd);\n+\t\tif (namelen2 >= PATH_MAX)\n+\t\t\tdie(\"path too long\");\n+\t\tstrcpy(fullpath, prefix_to_cwd);\n+\t\ttype = 0;\n+\t} else\n+\tif (type == 2) {\n+\t\tif (!fixup) goto done;\n+\t} else\n+\tif (type == 3)\n+\t\treturn;\t/* client will complain */\n+\tcp2 = strcat(fullpath, cp2);\n+\n+\twhile ((t = strstr(cp2, \"/./\")) != NULL)\n+\t\tmemmove(t, t + 2, (namelen2 -= 2) - (t - cp2) + 1);\n+\n+\twhile ((t = strstr(cp2, \"/../\")) != NULL) {\n+\t\tif (t == cp2 || (t == cp2 + 1 && t[-1] == '.'))\n+\t\t\treturn;\t/* client will complain */\n+\t\tfor (t2 = t; --t2 >= cp2 && *t2 != '/'; )\n+\t\t\t/* nothing */;\n+\t\tif (t2 < cp2) {\n+\t\t\tnamelen2 -= t + 4 - cp2;\n+\t\t\tcp2 = t + 4;\n+\t\t} else {\n+\t\t\tmemmove(t2, t + 3, namelen2 - (t + 3 - cp2) + 1);\n+\t\t\tnamelen2 -= t + 3 - t2;\n+\t\t}\n+\t}\n+\n+done:\t*cp = cp2 + type;\n+\t*namelen = namelen2 - type;\n+}\n+\n+/*\n * This interprets names like ':/Initial revision of \"git\"' by searching\n * through history and returning the first commit whose message starts\n * with the given string.\n@@ -647,6 +708,11 @@ int get_sha1(const char *name, unsigned char *sha1)\n \treturn get_sha1_with_mode(name, sha1, &unused);\n }\n \n+/*\n+ * Future: change to '?'\n+ */\n+#define\tENT_COLON_OLD_SEARCH\t'/'\n+\n int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n {\n \tint ret, bracket_depth;\n@@ -666,7 +732,8 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \t\tint stage = 0;\n \t\tstruct cache_entry *ce;\n \t\tint pos;\n-\t\tif (namelen > 2 && name[1] == '/')\n+\t\tif (namelen > 2 &&\n+\t\t (name[1] == ENT_COLON_OLD_SEARCH || name[1] == '?'))\n \t\t\treturn get_sha1_oneline(name + 2, sha1);\n \t\tif (namelen < 3 ||\n \t\t name[2] != ':' ||\n@@ -681,6 +748,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n \t\t\tread_cache();\n \t\tif (active_nr < 0)\n \t\t\treturn -1;\n+\t\tprepend_prefix(&cp, &namelen);\n \t\tpos = cache_name_pos(cp, namelen);\n \t\tif (pos < 0)\n \t\t\tpos = -pos - 1;\n@@ -708,9 +776,11 @@ 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\tnamelen -= ++cp - name;\n+\t\t\tprepend_prefix(&cp, &namelen);\n+\t\t\treturn get_tree_entry(tree_sha1, cp, sha1, mode);\n+\t\t}\n \t}\n \treturn ret;\n }\n-- \n1.5.2.rc0.787.g0014\n"},{"id":"41110","messageId":"f1glk1$6qh$1@sea.gmane.org","threadId":"7979","inReplyTo":"463BD40C.6080909@gmail.com","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-05T01:11:27Z","receivedAt":"2007-05-05T01:11:27Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dana How wrote:\n\n> Most commands accept relative paths,  but this is\n> not true of arguments in ent:path format.  This\n> patch makes all of the following git-show commands\n> work in the git source tree (not just the first):\n>\n>  % cd xdiff\n>  % git-show v1.5.2-rc0:xdiff/xemit.h\n>  % git-show v1.5.2-rc0:./xemit.h\n>  % git-show v1.5.2-rc0:../sha1_name.c\n> \n> It also adds ent:?string as a synonym for ent:/string .\n> This makes the following changes possible later:\n> ent:/path is an absolute path and ent:path is relative.\n\nFirst, we now usually use 'tree-ish' or 'treeish', not 'ent'.\nSecond, it is ':/', not ':/'\n\ngit-rev-parse(1):\n\n * A colon, followed by a slash, followed by a text: this names\n a commit whose commit message starts with the specified text.\n This name returns the youngest matching commit which is\n reachable from any ref. If the commit message starts with a\n '!', you have to repeat that; the special sequence ':/!',\n followed by something else than '!' is reserved for now.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"41112","messageId":"Pine.LNX.4.64.0705050324580.4015@racer.site","threadId":"7979","inReplyTo":"463BD40C.6080909@gmail.com","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-05T01:29:44Z","receivedAt":"2007-05-05T01:29:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 4 May 2007, Dana How wrote:\n\n> Most commands accept relative paths, but this is\n> not true of arguments in ent:path format. This\n> patch makes all of the following git-show commands\n> work in the git source tree (not just the first):\n> % cd xdiff\n> % git-show v1.5.2-rc0:xdiff/xemit.h\n> % git-show v1.5.2-rc0:./xemit.h\n> % git-show v1.5.2-rc0:../sha1_name.c\n\nACK.\n\n> It also adds ent:?string as a synonym for ent:/string .\n> This makes the following changes possible later:\n> ent:/path is an absolute path and ent:path is relative.\n\nNACK. The \"?\" thing is highly unintuitive, and I still do not think that \nit is worth the confusion to make Git behave funny on \n:.\n\nThink of the \"todo\" branch, for example. And this is not even far fetched. \nIn many repositories I have to have separate related, but non-branch \nHEADs. For example, I track some projects with custom scripts. These \nscripts do _not_ belong into that branch. However, they are related, so I \nstore them in the same repository.\n\nPlus, my example of the bare-repository still has not been answered by \n_anyone_ in favour of changing the current behaviour.\n\nCiao,\nDscho\n"},{"id":"41113","messageId":"20070505033039.GD16538@spearce.org","threadId":"7979","inReplyTo":"Pine.LNX.4.64.0705050324580.4015@racer.site","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-05T03:30:39Z","receivedAt":"2007-05-05T03:30:39Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Fri, 4 May 2007, Dana How wrote:\n> \n> > Most commands accept relative paths, but this is\n> > not true of arguments in ent:path format. This\n> > patch makes all of the following git-show commands\n> > work in the git source tree (not just the first):\n> > % cd xdiff\n> > % git-show v1.5.2-rc0:xdiff/xemit.h\n> > % git-show v1.5.2-rc0:./xemit.h\n> > % git-show v1.5.2-rc0:../sha1_name.c\n> \n> ACK.\n\nDouble ACK. I'm in complete agreement with every point Dscho has\nmade in this thread, even if I haven't quoted it. ;-)\n\nI *really* do not want to see \":\" to mean include\nthe current prefix, *especially* when a bare repository is involved.\n\nI often either do ad-hoc git-show lines against bare repositories,\nor have scripts that depend on this existing absolute path behavior.\nI'd like to see those not break. ;-)\n\nSince \".\" and \"..\" should not be valid names in any tree of a Git\nrepository I think we're OK to say that \":./\" and \":../\" are to\nimply relative to current prefix. But if we do \":../\" then we also\nhave to do \":../../../../../../..\" ;-)\n\n-- \nShawn.\n"},{"id":"41114","messageId":"7vwszolz26.fsf@assigned-by-dhcp.cox.net","threadId":"7979","inReplyTo":"Pine.LNX.4.64.0705050324580.4015@racer.site","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-05T03:38:41Z","receivedAt":"2007-05-05T03:38:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Think of the \"todo\" branch, for example. And this is not even far fetched. \n> In many repositories I have to have separate related, but non-branch \n> HEADs. For example, I track some projects with custom scripts. These \n> scripts do _not_ belong into that branch. However, they are related, so I \n> store them in the same repository.\n\nI said I won't talk about it until 1.5.2 final, but you forced\nme into it.\n\n> Plus, my example of the bare-repository still has not been answered by \n> _anyone_ in favour of changing the current behaviour.\n\nI am not sure if there is anything to answer on this one.\n\nWhen you are talking to a bare-repository, your place relative\nto the root of the working tree is clearly undefined, and it is\nnatural that \":./\", \":/\" and\n\":\" cannot mean anything but relative to the\nroot of the tree-ish. \":../\" is obviously\nnonsense. So it does not matter if unadorned is relative\nto cwd or root in this case.\n\nYour other example, however, gives a much better illustration.\nAn unrelated 'todo' branch where your cwd does not have any\nrelevance to the contents of that tree-ish, or worse yet, a\ncommit from git-gui project in git.git repository, where taking\nyour cwd into account has an actively wrong effect, demonstrates\nwhy we would need a way to say \"By this path, I mean from the\ntop, I do not want you to take it as relative to where I am\".\n\nOne way to ensure that is to keep the current \"it is a path from\nthe top\" behaviour, and extended it with \"... unless it begins\nwith ./\". Doing this forever however penalizes the case where\nyou want to use relative paths by requiring ./ at the beginning.\n\nAnother is to do the usual POSIXy path interpretation and\n\"unless it begins with /, it is taken as relative to where you\nare\". This penalizes the 'todo' and git-gui commit use case\nbecause the user explicitly needs to say \"where I am does not\nmatter\" by prefixing the path with '/', and also necessitates a\nchange to the syntax for looking backwards for a commit with\nthat message, because the existing syntax to look for a string\nclashes with it [*1*].\n\nBoth have merits and demerits. If we did not have any existing\ncode and users, the latter is clearly what we would have done,\nas it is more consistent. The path handling feels more natural\n(in line with the way we expect paths to be handled on POSIX\nsystems), the \"look backwards\" search feels more natural ( you\nuse '/' for forward search, '?' for backwards).\n\nI also suspect the latter is more often convenient. When\nworking on a flat project, it does not matter if the default is\nrelative to cwd or to the root. But if your project is deep,\nand if you somehow do \"git show\" more often than \"git diff\" (I\ndon't, but different people may do so for different reasons), it\nwould start to hurt if you always have to say \"./\".\n\nIt is however clearly a bigger change to existing users.\nCorrecting earlier mistakes is painful, so it certainly is\ntempting to take the approach that the path is always absolute\nand require \"./\" for relative. I agree it is an easier change,\nbut I am not convinced yet that it is the right design in the\nlonger term.\n\n[Footnote]\n\n*1* This is only true for looking for a path in the index case,\nas :/ does not seem to work. I think this is a\nbug in the current code -- shouldn't it limit the search to\ncommits that are reachable from that named one?\n"},{"id":"41121","messageId":"56b7f5510705042346s759a2ef9tfa3a223fe7af7c16@mail.gmail.com","threadId":"7979","inReplyTo":"7vwszolz26.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-05T06:46:46Z","receivedAt":"2007-05-05T06:46:46Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"Thanks for your reply. I can wait for 1.5.2.\nSo I will _quickly_ address some other points JS and SP mentioned.\n\n(a) In a bare repository, I believe setup.c:setup_git_directory_gently()\ndetermines the prefix to be NULL. This means my patch will see\nALL paths as absolute, except :../path which will result in an error.\n\n(b) For :path and :stage:path , relative is useful for me.\n\n(c) For :path , again relative is useful for me.\nAll my examples were of this form.\n\n(d) Where in :path is just a tree and no\ncommit is involved, relative paths make no sense since you don't\nknow where the tree is. (Imagine it moved between commits.)\nSo don't call my prepend_prefix() or call it with prefix faked to NULL.\n\nUnfortunately I was never clear about (a) and my patch fails\nto discriminate between (c) and (d). I'll try to fix the latter later.\n\nThanks\n\nDana\n\nOn 5/4/07, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n>\n> > Think of the \"todo\" branch, for example. And this is not even far fetched.\n> > In many repositories I have to have separate related, but non-branch\n> > HEADs. For example, I track some projects with custom scripts. These\n> > scripts do _not_ belong into that branch. However, they are related, so I\n> > store them in the same repository.\n>\n> I said I won't talk about it until 1.5.2 final, but you forced\n> me into it.\n>\n> > Plus, my example of the bare-repository still has not been answered by\n> > _anyone_ in favour of changing the current behaviour.\n>\n> I am not sure if there is anything to answer on this one.\n>\n> When you are talking to a bare-repository, your place relative\n> to the root of the working tree is clearly undefined, and it is\n> natural that \":./\", \":/\" and\n> \":\" cannot mean anything but relative to the\n> root of the tree-ish. \":../\" is obviously\n> nonsense. So it does not matter if unadorned is relative\n> to cwd or root in this case.\n>\n> Your other example, however, gives a much better illustration.\n> An unrelated 'todo' branch where your cwd does not have any\n> relevance to the contents of that tree-ish, or worse yet, a\n> commit from git-gui project in git.git repository, where taking\n> your cwd into account has an actively wrong effect, demonstrates\n> why we would need a way to say \"By this path, I mean from the\n> top, I do not want you to take it as relative to where I am\".\n>\n> One way to ensure that is to keep the current \"it is a path from\n> the top\" behaviour, and extended it with \"... unless it begins\n> with ./\". Doing this forever however penalizes the case where\n> you want to use relative paths by requiring ./ at the beginning.\n>\n> Another is to do the usual POSIXy path interpretation and\n> \"unless it begins with /, it is taken as relative to where you\n> are\". This penalizes the 'todo' and git-gui commit use case\n> because the user explicitly needs to say \"where I am does not\n> matter\" by prefixing the path with '/', and also necessitates a\n> change to the syntax for looking backwards for a commit with\n> that message, because the existing syntax to look for a string\n> clashes with it [*1*].\n>\n> Both have merits and demerits. If we did not have any existing\n> code and users, the latter is clearly what we would have done,\n> as it is more consistent. The path handling feels more natural\n> (in line with the way we expect paths to be handled on POSIX\n> systems), the \"look backwards\" search feels more natural ( you\n> use '/' for forward search, '?' for backwards).\n>\n> I also suspect the latter is more often convenient. When\n> working on a flat project, it does not matter if the default is\n> relative to cwd or to the root. But if your project is deep,\n> and if you somehow do \"git show\" more often than \"git diff\" (I\n> don't, but different people may do so for different reasons), it\n> would start to hurt if you always have to say \"./\".\n>\n> It is however clearly a bigger change to existing users.\n> Correcting earlier mistakes is painful, so it certainly is\n> tempting to take the approach that the path is always absolute\n> and require \"./\" for relative. I agree it is an easier change,\n> but I am not convinced yet that it is the right design in the\n> longer term.\n>\n> [Footnote]\n>\n> *1* This is only true for looking for a path in the index case,\n> as :/ does not seem to work. I think this is a\n> bug in the current code -- shouldn't it limit the search to\n> commits that are reachable from that named one?\n\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41124","messageId":"20070505080339.GA2585@steel.home","threadId":"7979","inReplyTo":"56b7f5510705042346s759a2ef9tfa3a223fe7af7c16@mail.gmail.com","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-05T08:03:39Z","receivedAt":"2007-05-05T08:03:39Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dana How, Sat, May 05, 2007 08:46:46 +0200:\n> Thanks for your reply. I can wait for 1.5.2.\n\nActually, you (and everyone who likes your patch and the proposed\nsemantics) can wait indefinitely. Just keep the patch in a side branch\nand rebase it or merge with Junio's master occasionally.\nI believe many of us have some features they keep in their repos which\nthey never send upstream (for their own reasons. I customized some\nwarnings and added printing of ip addresses to git-fetch. Not\ninteresting for everyone, but is useful next time kernel.org has DNS\nproblems). Just become the maintainer of the feature.\n"},{"id":"41131","messageId":"Pine.LNX.4.64.0705051637450.4015@racer.site","threadId":"7979","inReplyTo":"56b7f5510705042346s759a2ef9tfa3a223fe7af7c16@mail.gmail.com","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-05T14:39:00Z","receivedAt":"2007-05-05T14:39:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 4 May 2007, Dana How wrote:\n\n> (a) In a bare repository, I believe setup.c:setup_git_directory_gently()\n> determines the prefix to be NULL. This means my patch will see\n> ALL paths as absolute, except :../path which will result in an error.\n\nMy point was that it feels inconsistent to take the current path into \naccount in one case, but not in the other.\n\nCiao,\nDscho\n"},{"id":"41157","messageId":"20070505193214.GD30511@admingilde.org","threadId":"7979","inReplyTo":"20070505033039.GD16538@spearce.org","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-05-05T19:32:14Z","receivedAt":"2007-05-05T19:32:14Z","isPatch":true,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"On Fri, May 04, 2007 at 11:30:39PM -0400, Shawn O. Pearce wrote:\n> Johannes Schindelin wrote:\n> > On Fri, 4 May 2007, Dana How wrote:\n> > \n> > > Most commands accept relative paths, but this is\n> > > not true of arguments in ent:path format. This\n> > > patch makes all of the following git-show commands\n> > > work in the git source tree (not just the first):\n> > > % cd xdiff\n> > > % git-show v1.5.2-rc0:xdiff/xemit.h\n> > > % git-show v1.5.2-rc0:./xemit.h\n> > > % git-show v1.5.2-rc0:../sha1_name.c\n> > \n> > ACK.\n> \n> Double ACK. I'm in complete agreement with every point Dscho has\n> made in this thread, even if I haven't quoted it. ;-)\n> \n> I *really* do not want to see \":\" to mean include\n> the current prefix, *especially* when a bare repository is involved.\n\nwe could also introduce \"/\" for absolute path entries.\nThis would make a lot of sense for submodules:\n\n\tgit show \"/path/to/submodule/path/inside/submodule\n\nwith only : it would not look that nice ;-)\nOK, we could simply say that submodules are special and that you\ndon't have to use : to separate a commit (the submodule entry) from\nthe path inside.\n\n\naside from that I would also really like to have both absolute and\nrelative ways to name objects.\n\n-- \nMartin Waitz\n"},{"id":"41159","messageId":"7vy7k3hvog.fsf@assigned-by-dhcp.cox.net","threadId":"7979","inReplyTo":"20070505193214.GD30511@admingilde.org","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-05T20:17:35Z","receivedAt":"2007-05-05T20:17:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Waitz writes:\n\n> we could also introduce \"/\" for absolute path entries.\n\nWhen you name the tree-ish with usual \"branch name\", where does\nthe branch name end and pathname start? What happens when there\nis an ambiguity, and how costly to detect such an ambiguity to\nbegin with?\n"},{"id":"41160","messageId":"20070505203715.GC2898@steel.home","threadId":"7979","inReplyTo":"20070505193214.GD30511@admingilde.org","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-05T20:37:15Z","receivedAt":"2007-05-05T20:37:15Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Martin Waitz, Sat, May 05, 2007 21:32:14 +0200:\n> we could also introduce \"/\" for absolute path entries.\n\n\"012345/abc/def\"\n\nIs it a relative path, or a tree-ish + absolute path?\n"},{"id":"41162","messageId":"20070505211857.GE30511@admingilde.org","threadId":"7979","inReplyTo":"7vy7k3hvog.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-05-05T21:18:57Z","receivedAt":"2007-05-05T21:18:57Z","isPatch":true,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Sat, May 05, 2007 at 01:17:35PM -0700, Junio C Hamano wrote:\n> > we could also introduce \"/\" for absolute path entries.\n> \n> When you name the tree-ish with usual \"branch name\", where does\n> the branch name end and pathname start? What happens when there\n> is an ambiguity, and how costly to detect such an ambiguity to\n> begin with?\n\nwell, if you know that it starts with a tree-ish there is no\nambiguity as there can't be any \"a/b\" tree-ish if there already is one\nnamed \"a\". But Alex is right, it can be confused with an relative\npath if e.g. git-log is used without \"--\".\n\nBut for submodules I'd really like the / syntax.\n\n-- \nMartin Waitz\n"},{"id":"41167","messageId":"Pine.LNX.4.64.0705060259460.4015@racer.site","threadId":"7979","inReplyTo":"20070505211857.GE30511@admingilde.org","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-06T00:59:55Z","receivedAt":"2007-05-06T00:59:55Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 5 May 2007, Martin Waitz wrote:\n\n> hoi :)\n> \n> On Sat, May 05, 2007 at 01:17:35PM -0700, Junio C Hamano wrote:\n> > > we could also introduce \"/\" for absolute path entries.\n> > \n> > When you name the tree-ish with usual \"branch name\", where does\n> > the branch name end and pathname start? What happens when there\n> > is an ambiguity, and how costly to detect such an ambiguity to\n> > begin with?\n> \n> well, if you know that it starts with a tree-ish there is no\n> ambiguity [...]\n\nWrong. For example, mw/submodules~10 _is_ a tree-ish (if you have a branch \nnamed \"mw/submodules\").\n\nHth,\nDscho\n"},{"id":"41178","messageId":"7vwszmfod8.fsf@assigned-by-dhcp.cox.net","threadId":"7979","inReplyTo":"Pine.LNX.4.64.0705051637450.4015@racer.site","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-06T06:38:27Z","receivedAt":"2007-05-06T06:38:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> (a) In a bare repository, I believe setup.c:setup_git_directory_gently()\n>> determines the prefix to be NULL. This means my patch will see\n>> ALL paths as absolute, except :../path which will result in an error.\n>\n> My point was that it feels inconsistent to take the current path into \n> account in one case, but not in the other.\n\nI do not understand your reasoning. In a bare repository you\ncannot even be in a subdirectory to begin with.\n"},{"id":"41213","messageId":"Pine.LNX.4.64.0705061653100.4015@racer.site","threadId":"7979","inReplyTo":"7vwszmfod8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-06T15:14:36Z","receivedAt":"2007-05-06T15:14:36Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 5 May 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> (a) In a bare repository, I believe \n> >> setup.c:setup_git_directory_gently() determines the prefix to be \n> >> NULL. This means my patch will see ALL paths as absolute, except \n> >> :../path which will result in an error.\n> >\n> > My point was that it feels inconsistent to take the current path into \n> > account in one case, but not in the other.\n> \n> I do not understand your reasoning. In a bare repository you cannot \n> even be in a subdirectory to begin with.\n\nExactly! That is my point. If you can do it in a working directory, but \nalso with a bare repository, I find it highly confusing and inconsistent \nto have different meaning.\n\nCiao,\nDscho\n"},{"id":"41226","messageId":"7v1whtdfd2.fsf@assigned-by-dhcp.cox.net","threadId":"7979","inReplyTo":"Pine.LNX.4.64.0705061653100.4015@racer.site","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-06T17:35:53Z","receivedAt":"2007-05-06T17:35:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 5 May 2007, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> >> (a) In a bare repository, I believe \n>> >> setup.c:setup_git_directory_gently() determines the prefix to be \n>> >> NULL. This means my patch will see ALL paths as absolute, except \n>> >> :../path which will result in an error.\n>> >\n>> > My point was that it feels inconsistent to take the current path into \n>> > account in one case, but not in the other.\n>> \n>> I do not understand your reasoning. In a bare repository you cannot \n>> even be in a subdirectory to begin with.\n>\n> Exactly! That is my point. If you can do it in a working directory, but \n> also with a bare repository, I find it highly confusing and inconsistent \n> to have different meaning.\n\nSorry. Now you confused me further. I can do:\n\n\tcd Documentation\n git diff v1.5.0 v1.5.1 -- git.txt\n\nIs that confusing, inconsistent and bad for the users?\n"},{"id":"41234","messageId":"20070506185259.GF30511@admingilde.org","threadId":"7979","inReplyTo":"Pine.LNX.4.64.0705060259460.4015@racer.site","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-05-06T18:52:59Z","receivedAt":"2007-05-06T18:52:59Z","isPatch":true,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Sun, May 06, 2007 at 02:59:55AM +0200, Johannes Schindelin wrote:\n> > On Sat, May 05, 2007 at 01:17:35PM -0700, Junio C Hamano wrote:\n> > > > we could also introduce \"/\" for absolute path entries.\n> > > \n> > > When you name the tree-ish with usual \"branch name\", where does\n> > > the branch name end and pathname start? What happens when there\n> > > is an ambiguity, and how costly to detect such an ambiguity to\n> > > begin with?\n> > \n> > well, if you know that it starts with a tree-ish there is no\n> > ambiguity [...]\n> \n> Wrong. For example, mw/submodules~10 _is_ a tree-ish (if you have a branch \n> named \"mw/submodules\").\n\nso what?\n\na better argument is that one can have both refs/tags/a and\nrefs/heads/a/b.\n\nSo just forget my suggestion...\n\n-- \nMartin Waitz\n"},{"id":"41269","messageId":"Pine.LNX.4.64.0705070108380.4167@racer.site","threadId":"7979","inReplyTo":"20070506185259.GF30511@admingilde.org","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-06T23:09:49Z","receivedAt":"2007-05-06T23:09:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 6 May 2007, Martin Waitz wrote:\n\n> On Sun, May 06, 2007 at 02:59:55AM +0200, Johannes Schindelin wrote:\n> > > On Sat, May 05, 2007 at 01:17:35PM -0700, Junio C Hamano wrote:\n> > > > > we could also introduce \"/\" for absolute path entries.\n> > > > \n> > > > When you name the tree-ish with usual \"branch name\", where does\n> > > > the branch name end and pathname start? What happens when there\n> > > > is an ambiguity, and how costly to detect such an ambiguity to\n> > > > begin with?\n> > > \n> > > well, if you know that it starts with a tree-ish there is no\n> > > ambiguity [...]\n> > \n> > Wrong. For example, mw/submodules~10 _is_ a tree-ish (if you have a branch \n> > named \"mw/submodules\").\n> \n> so what?\n\nSo what: it proves that your case is wrong. mw/submodules~10/README would \nbe _severely_ confused.\n\nCiao,\nDscho\n"},{"id":"41270","messageId":"Pine.LNX.4.64.0705070110040.4167@racer.site","threadId":"7979","inReplyTo":"7v1whtdfd2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-06T23:12:23Z","receivedAt":"2007-05-06T23:12:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 6 May 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sat, 5 May 2007, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> >> (a) In a bare repository, I believe \n> >> >> setup.c:setup_git_directory_gently() determines the prefix to be \n> >> >> NULL. This means my patch will see ALL paths as absolute, except \n> >> >> :../path which will result in an error.\n> >> >\n> >> > My point was that it feels inconsistent to take the current path into \n> >> > account in one case, but not in the other.\n> >> \n> >> I do not understand your reasoning. In a bare repository you cannot \n> >> even be in a subdirectory to begin with.\n> >\n> > Exactly! That is my point. If you can do it in a working directory, but \n> > also with a bare repository, I find it highly confusing and inconsistent \n> > to have different meaning.\n> \n> Sorry. Now you confused me further. I can do:\n> \n> \tcd Documentation\n> git diff v1.5.0 v1.5.1 -- git.txt\n> \n> Is that confusing, inconsistent and bad for the users?\n\nWell, I am partly at fault that you _can_ execute git-diff outside of a \nrepository.\n\nBut given the _arguments_ you give to git-diff as above, I'd expect it to \nactually care about the working directory. IOW I would _not_ expect this \nto work outside of a working directory (even if it does).\n\nCiao,\nDscho\n"},{"id":"41275","messageId":"7v6475bi69.fsf@assigned-by-dhcp.cox.net","threadId":"7979","inReplyTo":"Pine.LNX.4.64.0705070110040.4167@racer.site","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-07T00:18:06Z","receivedAt":"2007-05-07T00:18:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sun, 6 May 2007, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > On Sat, 5 May 2007, Junio C Hamano wrote:\n>> >\n>> >> Johannes Schindelin writes:\n>> >> \n>> >> >> (a) In a bare repository, I believe \n>> >> >> setup.c:setup_git_directory_gently() determines the prefix to be \n>> >> >> NULL. This means my patch will see ALL paths as absolute, except \n>> >> >> :../path which will result in an error.\n>> >> >\n>> >> > My point was that it feels inconsistent to take the current path into \n>> >> > account in one case, but not in the other.\n>> >> \n>> >> I do not understand your reasoning. In a bare repository you cannot \n>> >> even be in a subdirectory to begin with.\n>> >\n>> > Exactly! That is my point. If you can do it in a working directory, but \n>> > also with a bare repository, I find it highly confusing and inconsistent \n>> > to have different meaning.\n>> \n>> Sorry. Now you confused me further. I can do:\n>> \n>> \tcd Documentation\n>> git diff v1.5.0 v1.5.1 -- git.txt\n>> \n>> Is that confusing, inconsistent and bad for the users?\n>\n> Well, I am partly at fault that you _can_ execute git-diff outside of a \n> repository.\n>\n> But given the _arguments_ you give to git-diff as above, I'd expect it to \n> actually care about the working directory. IOW I would _not_ expect this \n> to work outside of a working directory (even if it does).\n\nOh, I was not thinking about \"outside of repository\" use. I was\ntalking about your earlier \"bare repository vs inside worktree\nvs inside a subdirectory of worktree\" point. In a bare\nrepository,\n\n\tgit diff v1.5.0 v1.5.1 -- Documentation/git.txt\n\nis the only form that makes sense, as you cannot say \"I am\ninterested in Documentation/\" by _being_ in that subdirectory.\nIn a repository with worktree, you can, and we let you do so.\n\nI would expect v1.5.0:Documentation/git.txt notation would be\nthe only sane variant that would make sense to name that blob in\na bare repository for the same reason. I do not expect anybody\nto complain because we do not allow him to say v1.5.0:git.txt in\na bare repository, either.\n\nAlso I sympathize with people who would wish to (eventually) be\nable to do:\n\n\t$ cd Documentation/\n\t$ git show v1.5.0:git.txt\n\nin a repository with worktree, by making the \"relative path\" the\ndefault behaviour. They would need to do either one of:\n\n\t$ git show v1.5.0:/git.c\n\t$ git show v1.5.0:../git.c\n\nif we ever made the \"relative path\" the default. As long as you\nmake sure that you make:\n\n\t$ git show v1.5.0:/git.c\n\nwork the same way in a bare repository _if_ we make the\n\"relative path\" the default, I do not see any inconsistency\nproblem there.\n\nA bare repository and a repository with working tree are\ndifferent. In the former, you cannot say \"I am interested in\nthis subtree\" by _being_ in a subdirectory; in the latter you\ncan. Taking advantage of that and allowing the user to express\nhimself better (only) in the latter is not an inconsistency.\nNot being able to do that in a bare repository comes from what a\nbare repository inherently is.\n"},{"id":"41276","messageId":"56b7f5510705061737g3f7cd443i47175f67f13eb059@mail.gmail.com","threadId":"7979","inReplyTo":"7v6475bi69.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH v3] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-07T00:37:48Z","receivedAt":"2007-05-07T00:37:48Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/6/07, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n>\n> > On Sun, 6 May 2007, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >>\n> >> > On Sat, 5 May 2007, Junio C Hamano wrote:\n> >> >\n> >> >> Johannes Schindelin writes:\n> >> >>\n> >> >> >> (a) In a bare repository, I believe\n> >> >> >> setup.c:setup_git_directory_gently() determines the prefix to be\n> >> >> >> NULL. This means my patch will see ALL paths as absolute, except\n> >> >> >> :../path which will result in an error.\n> >> >> >\n> >> >> > My point was that it feels inconsistent to take the current path into\n> >> >> > account in one case, but not in the other.\n> >> >>\n> >> >> I do not understand your reasoning. In a bare repository you cannot\n> >> >> even be in a subdirectory to begin with.\n> >> >\n> >> > Exactly! That is my point. If you can do it in a working directory, but\n> >> > also with a bare repository, I find it highly confusing and inconsistent\n> >> > to have different meaning.\n> >>\n> >> Sorry. Now you confused me further. I can do:\n> >>\n> >> cd Documentation\n> >> git diff v1.5.0 v1.5.1 -- git.txt\n> >>\n> >> Is that confusing, inconsistent and bad for the users?\n> >\n> > Well, I am partly at fault that you _can_ execute git-diff outside of a\n> > repository.\n> >\n> > But given the _arguments_ you give to git-diff as above, I'd expect it to\n> > actually care about the working directory. IOW I would _not_ expect this\n> > to work outside of a working directory (even if it does).\n>\n> Oh, I was not thinking about \"outside of repository\" use. I was\n> talking about your earlier \"bare repository vs inside worktree\n> vs inside a subdirectory of worktree\" point. In a bare\n> repository,\n>\n> git diff v1.5.0 v1.5.1 -- Documentation/git.txt\n>\n> is the only form that makes sense, as you cannot say \"I am\n> interested in Documentation/\" by _being_ in that subdirectory.\n> In a repository with worktree, you can, and we let you do so.\n>\n> I would expect v1.5.0:Documentation/git.txt notation would be\n> the only sane variant that would make sense to name that blob in\n> a bare repository for the same reason. I do not expect anybody\n> to complain because we do not allow him to say v1.5.0:git.txt in\n> a bare repository, either.\n>\n> Also I sympathize with people who would wish to (eventually) be\n> able to do:\n>\n> $ cd Documentation/\n> $ git show v1.5.0:git.txt\n>\n> in a repository with worktree, by making the \"relative path\" the\n> default behaviour. They would need to do either one of:\n>\n> $ git show v1.5.0:/git.c\n> $ git show v1.5.0:../git.c\n>\n> if we ever made the \"relative path\" the default. As long as you\n> make sure that you make:\n>\n> $ git show v1.5.0:/git.c\n>\n> work the same way in a bare repository _if_ we make the\n> \"relative path\" the default, I do not see any inconsistency\n> problem there.\n>\n> A bare repository and a repository with working tree are\n> different. In the former, you cannot say \"I am interested in\n> this subtree\" by _being_ in a subdirectory; in the latter you\n> can. Taking advantage of that and allowing the user to express\n> himself better (only) in the latter is not an inconsistency.\n> Not being able to do that in a bare repository comes from what a\n> bare repository inherently is.\n\nEach of the examples given already works as described above\nin the current patch [if you change one #define to enable\n\"relative is default\"]. I will get around to fixing the one\nerror I described elsewhere and re-submit.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"}]}