{"thread":{"id":"7967","subject":"[PATCH] Support ent:relative_path","startedAt":"2007-05-04T07:18:41Z","lastAt":"2007-05-05T01:15:21Z","messageCount":28,"participants":["Dana How","Alex Riesen","Junio C Hamano","Johannes Sixt","Johannes Schindelin","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"41011","messageId":"463ADE51.2030108@gmail.com","threadId":"7967","inReplyTo":null,"subject":"[PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-04T07:18:41Z","receivedAt":"2007-05-04T07:18:41Z","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 3 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-config --bool core.relativepaths yes\n % git-show v1.5.2-rc0:xemit.h\n\nSigned-off-by: Dana L. How \n---\n cache.h | 2 ++\n config.c | 5 +++++\n environment.c | 1 +\n setup.c | 5 ++++-\n sha1_name.c | 27 ++++++++++++++++++++++++---\n 5 files changed, 36 insertions(+), 4 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 8e76152..fc3fcb1 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);\n@@ -276,6 +277,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);\n extern int use_legacy_headers;\n extern int trust_executable_bit;\n extern int has_symlinks;\n+extern int assume_relative_paths;\n extern int assume_unchanged;\n extern int prefer_symlink_refs;\n extern int log_all_ref_updates;\ndiff --git a/config.c b/config.c\nindex 70d1055..7525965 100644\n--- a/config.c\n+++ b/config.c\n@@ -279,6 +279,11 @@ int git_default_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.relativepaths\")) {\n+\t\tassume_relative_paths = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n \tif (!strcmp(var, \"core.ignorestat\")) {\n \t\tassume_unchanged = git_config_bool(var, value);\n \t\treturn 0;\ndiff --git a/environment.c b/environment.c\nindex 2231659..f1b867d 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -14,6 +14,7 @@ char git_default_name[MAX_GITNAME];\n int use_legacy_headers = 1;\n int trust_executable_bit = 1;\n int has_symlinks = 1;\n+int assume_relative_paths;\n int assume_unchanged;\n int prefer_symlink_refs;\n int is_bare_repository_cfg = -1; /* unspecified */\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..0b9e92c 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -592,6 +592,24 @@ static int handle_one_ref(const char *path,\n \treturn 0;\n }\n \n+static void prepend_prefix(const char **cp, int *namelen)\n+{\n+\tstatic char fullpath[PATH_MAX];\n+\tif (*namelen > 2 && !memcmp(*cp, \"./\", 2)) {\n+\t\t*cp += 2;\n+\t\t*namelen -= 2;\n+\t} else\n+\tif (!assume_relative_paths || !prefix_to_cwd)\n+\t\treturn;\n+\n+\t*namelen += strlen(prefix_to_cwd);\n+\tif (*namelen >= PATH_MAX)\n+\t\tdie(\"path too long\");\n+\tstrcpy(fullpath, prefix_to_cwd);\n+\tstrcat(fullpath, *cp);\n+\t*cp = fullpath;\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@@ -681,6 +699,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 +727,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":"41013","messageId":"56b7f5510705040022x2e4903d3hbe4ac1ee1a2e096f@mail.gmail.com","threadId":"7967","inReplyTo":"463ADE51.2030108@gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-04T07:22:28Z","receivedAt":"2007-05-04T07:22:28Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"Yikes... the if's in prepend_prefix() need to be re-arranged.\n\nDana\n\nOn 5/4/07, 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 3 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-config --bool core.relativepaths yes\n> % git-show v1.5.2-rc0:xemit.h\n>\n> Signed-off-by: Dana L. How \n> ---\n> cache.h | 2 ++\n> config.c | 5 +++++\n> environment.c | 1 +\n> setup.c | 5 ++++-\n> sha1_name.c | 27 ++++++++++++++++++++++++---\n> 5 files changed, 36 insertions(+), 4 deletions(-)\n>\n> diff --git a/cache.h b/cache.h\n> index 8e76152..fc3fcb1 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);\n> @@ -276,6 +277,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);\n> extern int use_legacy_headers;\n> extern int trust_executable_bit;\n> extern int has_symlinks;\n> +extern int assume_relative_paths;\n> extern int assume_unchanged;\n> extern int prefer_symlink_refs;\n> extern int log_all_ref_updates;\n> diff --git a/config.c b/config.c\n> index 70d1055..7525965 100644\n> --- a/config.c\n> +++ b/config.c\n> @@ -279,6 +279,11 @@ int git_default_config(const char *var, const char *value)\n> return 0;\n> }\n>\n> + if (!strcmp(var, \"core.relativepaths\")) {\n> + assume_relative_paths = git_config_bool(var, value);\n> + return 0;\n> + }\n> +\n> if (!strcmp(var, \"core.ignorestat\")) {\n> assume_unchanged = git_config_bool(var, value);\n> return 0;\n> diff --git a/environment.c b/environment.c\n> index 2231659..f1b867d 100644\n> --- a/environment.c\n> +++ b/environment.c\n> @@ -14,6 +14,7 @@ char git_default_name[MAX_GITNAME];\n> int use_legacy_headers = 1;\n> int trust_executable_bit = 1;\n> int has_symlinks = 1;\n> +int assume_relative_paths;\n> int assume_unchanged;\n> int prefer_symlink_refs;\n> int is_bare_repository_cfg = -1; /* unspecified */\n> diff --git a/setup.c b/setup.c\n> index 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> const char *orig = path;\n> @@ -252,7 +254,8 @@ const char *setup_git_directory_gently(int *nongit_ok)\n> cwd[len++] = '/';\n> cwd[len] = 0;\n> inside_git_dir = !prefixcmp(cwd + offset, \".git/\");\n> - return cwd + offset;\n> + prefix_to_cwd = cwd + offset;\n> + return prefix_to_cwd;\n> }\n>\n> int git_config_perm(const char *var, const char *value)\n> diff --git a/sha1_name.c b/sha1_name.c\n> index 55f25a2..0b9e92c 100644\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -592,6 +592,24 @@ static int handle_one_ref(const char *path,\n> return 0;\n> }\n>\n> +static void prepend_prefix(const char **cp, int *namelen)\n> +{\n> + static char fullpath[PATH_MAX];\n> + if (*namelen > 2 && !memcmp(*cp, \"./\", 2)) {\n> + *cp += 2;\n> + *namelen -= 2;\n> + } else\n> + if (!assume_relative_paths || !prefix_to_cwd)\n> + return;\n> +\n> + *namelen += strlen(prefix_to_cwd);\n> + if (*namelen >= PATH_MAX)\n> + die(\"path too long\");\n> + strcpy(fullpath, prefix_to_cwd);\n> + strcat(fullpath, *cp);\n> + *cp = fullpath;\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> @@ -681,6 +699,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)\n> read_cache();\n> if (active_nr < 0)\n> return -1;\n> + prepend_prefix(&cp, &namelen);\n> pos = cache_name_pos(cp, namelen);\n> if (pos < 0)\n> pos = -pos - 1;\n> @@ -708,9 +727,11 @@ 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> + namelen -= ++cp - name;\n> + prepend_prefix(&cp, &namelen);\n> + return get_tree_entry(tree_sha1, cp, sha1, mode);\n> + }\n> }\n> return ret;\n> }\n> --\n> 1.5.2.rc0.787.g0014\n>\n>\n\n\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41018","messageId":"81b0412b0705040120r4ac596b9k72c354dff1cb1d0f@mail.gmail.com","threadId":"7967","inReplyTo":"463ADE51.2030108@gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T08:20:28Z","receivedAt":"2007-05-04T08:20:28Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Dana How wrote:\n> + if (!strcmp(var, \"core.relativepaths\")) {\n> + assume_relative_paths = git_config_bool(var, value);\n> + return 0;\n> + }\n\nMaybe we should use relative path always, unconditionally.\n"},{"id":"41019","messageId":"7v7irpuhhr.fsf@assigned-by-dhcp.cox.net","threadId":"7967","inReplyTo":"56b7f5510705040022x2e4903d3hbe4ac1ee1a2e096f@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-04T08:21:04Z","receivedAt":"2007-05-04T08:21:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I do not think it is wrong per-se, to want to make this hold true:\n\n\tA=$(git rev-parse :somedir/file)\n\tB=$(cd somedir && git rev-parse :file)\n test \"$A\" = \"$B\"\n\nOne thing I am reasonably certain however is that this should\nNOT be conditional to a config setting. Doing so would force\nscripts that take (or compute) path and commit and concatenate\nthem to make \"${commit}:${path}\" to name a blob (or tree) to\nfirst inspect the current setting of core.relativepaths and undo\nwhat the new code does by prefixing/subtracting the prefix\nstring depending on the config.\n\nIn other words, having that config is not really helping scripts\nor compatibility.\n\nI think the choices are:\n\n (1) we say it was a mistake that we did not make it relative to\n the current directory when we introduced the X:\n syntax (X could be empty or :[0-3]: for index, or a commit\n or tree object name), and change the semantics in a future\n major release for everybody, apologizing for potentially\n breaking existing scripts; or\n\n (2) keep the current behaviour as is, and come up with a\n different syntax to use relative; or\n\n (3) do nothing.\n\nMy preference is (2), (3) and then (1), but I do not have\noffhand a suggestion for a good metacharacter we could use.\n"},{"id":"41021","messageId":"56b7f5510705040145k781da6farff3d02c3c1a5f3f9@mail.gmail.com","threadId":"7967","inReplyTo":"7v7irpuhhr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-04T08:45:17Z","receivedAt":"2007-05-04T08:45:17Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/4/07, Junio C Hamano wrote:\n> I do not think it is wrong per-se, to want to make this hold true:\n>\n> A=$(git rev-parse :somedir/file)\n> B=$(cd somedir && git rev-parse :file)\n> test \"$A\" = \"$B\"\n>\n> One thing I am reasonably certain however is that this should\n> NOT be conditional to a config setting. Doing so would force\n> scripts that take (or compute) path and commit and concatenate\n> them to make \"${commit}:${path}\" to name a blob (or tree) to\n> first inspect the current setting of core.relativepaths and undo\n> what the new code does by prefixing/subtracting the prefix\n> string depending on the config.\n>\n> In other words, having that config is not really helping scripts\n> or compatibility.\n>\n> I think the choices are:\n>\n> (1) we say it was a mistake that we did not make it relative to\n> the current directory when we introduced the X:\n> syntax (X could be empty or :[0-3]: for index, or a commit\n> or tree object name), and change the semantics in a future\n> major release for everybody, apologizing for potentially\n> breaking existing scripts; or\n>\n> (2) keep the current behaviour as is, and come up with a\n> different syntax to use relative; or\n>\n> (3) do nothing.\n>\n> My preference is (2), (3) and then (1), but I do not have\n> offhand a suggestion for a good metacharacter we could use.\n\nLet us require:\n* No config settings as you prefer\n* Current interpretations are unchanged.\n\nThe current path supports\n :fullpath\n :/string\n :./relpath\n[assuming core.relativepaths=no always since it goes away].\n(:/string is the \"find string in commit msg\" feature.)\n\nA new metacharacter lets us drop the \"./\" ,\nand I think that's desirable.\nHow about = ? It's not even shifted on my keyboard:\n ent=relpath\n ent=2=relpath\n ent=/fullpath\n\n1. We would accept the same new metacharacter before stage if any.\n2, You could still use ent:/string , or ent:fullpath .\n\nThe patch should also be extended so relpath can start\nwith a sequence of ./ or ../ prefixes,\nwhich is easily handled in prepend_prefix()..\n\nWhat do you think of \"=\" ?\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41022","messageId":"81b0412b0705040147h1bab8f6ao3ce2c486637a0d4f@mail.gmail.com","threadId":"7967","inReplyTo":"7v7irpuhhr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T08:47:24Z","receivedAt":"2007-05-04T08:47:24Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Junio C Hamano wrote:\n> (1) we say it was a mistake that we did not make it relative to\n> the current directory when we introduced the X:\n> syntax (X could be empty or :[0-3]: for index, or a commit\n> or tree object name), and change the semantics in a future\n> major release for everybody, apologizing for potentially\n> breaking existing scripts; or\n\nThat would be my first prio preference\n\n> (2) keep the current behaviour as is, and come up with a\n> different syntax to use relative; or\n>\n> (3) do nothing.\n>\n> My preference is (2), (3) and then (1), but I do not have\n> offhand a suggestion for a good metacharacter we could use.\n\n\"./\" :)\n"},{"id":"41023","messageId":"56b7f5510705040153i65ba6260v9fbe7a90e040cab3@mail.gmail.com","threadId":"7967","inReplyTo":"81b0412b0705040147h1bab8f6ao3ce2c486637a0d4f@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-04T08:53:14Z","receivedAt":"2007-05-04T08:53:14Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/4/07, Alex Riesen wrote:\n> On 5/4/07, Junio C Hamano wrote:\n> > (1) we say it was a mistake that we did not make it relative to\n> > the current directory when we introduced the X:\n> > syntax (X could be empty or :[0-3]: for index, or a commit\n> > or tree object name), and change the semantics in a future\n> > major release for everybody, apologizing for potentially\n> > breaking existing scripts; or\n>\n> That would be my first prio preference\nMine too, but I don't want to break anything.\n\n> > (2) keep the current behaviour as is, and come up with a\n> > different syntax to use relative; or\n> >\n> > (3) do nothing.\n> >\n> > My preference is (2), (3) and then (1), but I do not have\n> > offhand a suggestion for a good metacharacter we could use.\n>\n> \"./\" :)\nHeh. Yes, that works in the current patch.\n\nI'm really starting to like the idea of introducing \"=\"\nas an alternative for \":\" :\n\"=\" assumes relative paths, \":\" assumes absolute (full) paths.\nThat could be Junio's new metacharacter.\n\nSince \"=\" is slightly easier to type [ ;-) ], and looks like a stretched \":\",\nit's almost ingenious...\n(Definitely getting carried away!)\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41024","messageId":"81b0412b0705040217o54d1d028j6e768bdc3eb0bad0@mail.gmail.com","threadId":"7967","inReplyTo":"56b7f5510705040153i65ba6260v9fbe7a90e040cab3@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T09:17:12Z","receivedAt":"2007-05-04T09:17:12Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Dana How wrote:\n> > > (1) we say it was a mistake that we did not make it relative to\n> > > the current directory when we introduced the X:\n> > > syntax (X could be empty or :[0-3]: for index, or a commit\n> > > or tree object name), and change the semantics in a future\n> > > major release for everybody, apologizing for potentially\n> > > breaking existing scripts; or\n> >\n> > That would be my first prio preference\n>\n> Mine too, but I don't want to break anything.\n\nIt probably wont break anything which is not already broken.\nIt's somehow hard to imagine someone would use the\nsyntax to check for absence of a file in non-top-level\nsubdirectory. Besides, the existing syntax is ambiguous:\nfor anyone using pathname tab completion.\n\nBesides, you can give a warning of ambiguity in case there are\nequal relative and a top-level paths. Return the relative, but print\nthe warning, so people can fix their scripts.\n\n> > > My preference is (2), (3) and then (1), but I do not have\n> > > offhand a suggestion for a good metacharacter we could use.\n> >\n> > \"./\" :)\n> Heh. Yes, that works in the current patch.\n>\n> I'm really starting to like the idea of introducing \"=\"\n> as an alternative for \":\" :\n> \"=\" assumes relative paths, \":\" assumes absolute (full) paths.\n> That could be Junio's new metacharacter.\n\nJust keep in mind: \"once introduced, you'll never be able to remove it\".\nAnd I don't share your feelings regarding the special character, for instance.\n\nI'd suggest to define a special character for _top_ level. Real pity\n\":/\" is taken.\n"},{"id":"41025","messageId":"463AFAAE.853DEF7B@eudaptics.com","threadId":"7967","inReplyTo":"81b0412b0705040147h1bab8f6ao3ce2c486637a0d4f@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-04T09:19:42Z","receivedAt":"2007-05-04T09:19:42Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Alex Riesen wrote:\n> On 5/4/07, Junio C Hamano wrote:\n> > My preference is (2), (3) and then (1), but I do not have\n> > offhand a suggestion for a good metacharacter we could use.\n> \n> \"./\" :)\n\n+1, without the :)\nand ../ should DWIM, too.\n\n-- Hannes\n"},{"id":"41027","messageId":"56b7f5510705040226o14d55b6euda7df1da7ad9b08a@mail.gmail.com","threadId":"7967","inReplyTo":"81b0412b0705040217o54d1d028j6e768bdc3eb0bad0@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-04T09:26:38Z","receivedAt":"2007-05-04T09:26:38Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/4/07, Alex Riesen wrote:\n> > > > My preference is (2), (3) and then (1), but I do not have\n> > > > offhand a suggestion for a good metacharacter we could use.\n> > >\n> > > \"./\" :)\n> > Heh. Yes, that works in the current patch.\n> >\n> > I'm really starting to like the idea of introducing \"=\"\n> > as an alternative for \":\" :\n> > \"=\" assumes relative paths, \":\" assumes absolute (full) paths.\n> > That could be Junio's new metacharacter.\n>\n> Just keep in mind: \"once introduced, you'll never be able to remove it\".\n> And I don't share your feelings regarding the special character, for instance.\nIndeed.\n\n> I'd suggest to define a special character for _top_ level. Real pity\n> \":/\" is taken.\nWe could use ://fullpath for top level,\nand :relpath for relative. Then \"string\" in :/string couldn't start with /,\nwhich shouldn't be a problem (right?). I've certainly seen double\nslashes before;\nperforce in fact uses them for the root of the repository (depot).\n\nThis all depends on deciding that :relpath should be the (incompatible)\nnew default, and I'm not sure that's going to happen.\n\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41029","messageId":"81b0412b0705040246r5a2726b8g4323cadeacee3aa7@mail.gmail.com","threadId":"7967","inReplyTo":"56b7f5510705040226o14d55b6euda7df1da7ad9b08a@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T09:46:38Z","receivedAt":"2007-05-04T09:46:38Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Dana How wrote:\n> > I'd suggest to define a special character for _top_ level. Real pity\n> > \":/\" is taken.\n> We could use ://fullpath for top level,\n\nNo good. How'd you find a commit starting with \"/\" than? (without\nchanging \":/\" syntax).\n\n> and :relpath for relative. Then \"string\" in :/string couldn't start with /,\n> which shouldn't be a problem (right?). I've certainly seen double\n> slashes before;\n> perforce in fact uses them for the root of the repository (depot).\n\nAnd I really hate perforce for its stupid redundancy (and changing of\nmeaning of well-known idioms: why should // be anything special\nbut plain top level or root?! Why the hell do they need them at if\nyou cannot use relative paths in client specs at all?! Why can't the\np4 command-line tool figure the fact from context or request the\ncontext be provided by user?! IOW, Perforce is a real bad example\nof how you do version control).\n\n> This all depends on deciding that :relpath should be the (incompatible)\n> new default, and I'm not sure that's going to happen.\n\nIf we are to stay that compatible, maybe \":./\" for relative paths and the\nold syntax left to mean top-level would the best choice for now.\n"},{"id":"41065","messageId":"56b7f5510705040957v4580b6c1xbe767892ada3bcde@mail.gmail.com","threadId":"7967","inReplyTo":"81b0412b0705040246r5a2726b8g4323cadeacee3aa7@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-04T16:57:12Z","receivedAt":"2007-05-04T16:57:12Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/4/07, Alex Riesen wrote:\n> On 5/4/07, Dana How wrote:\n> > > I'd suggest to define a special character for _top_ level. Real pity\n> > > \":/\" is taken.\n> > We could use ://fullpath for top level,\n>\n> No good. How'd you find a commit starting with \"/\" than? (without\n> changing \":/\" syntax).\nOh blechh. get_sha1_oneline uses prefixcmp(), not strstr().\nAre there are any commits in git or the kernel starting with \"/\" ?\n\n> > and :relpath for relative. Then \"string\" in :/string couldn't start with /,\n> > which shouldn't be a problem (right?). I've certainly seen double\n> > slashes before;\n> > perforce in fact uses them for the root of the repository (depot).\n>\n> And I really hate perforce for its stupid redundancy (and changing of\n> meaning of well-known idioms: why should // be anything special\n> but plain top level or root?! Why the hell do they need them at if\n> you cannot use relative paths in client specs at all?! Why can't the\n> p4 command-line tool figure the fact from context or request the\n> context be provided by user?! IOW, Perforce is a real bad example\n> of how you do version control).\nWhoa! I'm stuck using perforce too; I'm not holding it up as a *big*\nexample. I originally saw // meaning root in the Apollo DOMAIN\nsystem, so for that reason it makes sense to me. I think it also\nmeans network root in Windoze (well, \\\\ does ;-) )..\n\n> > This all depends on deciding that :relpath should be the (incompatible)\n> > new default, and I'm not sure that's going to happen.\n>\n> If we are to stay that compatible, maybe \":./\" for relative paths and the\n> old syntax left to mean top-level would the best choice for now.\n\nLet's summarize so far: I think everyone's convinced me we need\nto be careful, so this email will be more tedious than I'd like.\n\n(a) :./relpath clearly inidicates relative path. [Also take :../relpath .]\n(b) I'd like a more natural way to do :./relpath (e.g. :relpath),\n or at least a future path to such.\n(c) We would like to avoid new special characters beyond \":\".\n This means everything has to be done with \".\" and \"/\".\n(d) We are left with the following patterns:\n 1. :string\n 2. :/string\n 3. ://string\n\n[ We need a clear way to say relative, a clear way to say absolute,\nand the current :string can change from absolute to relative some time\nin the future if we so decide. ]\n\nIdeas for (d) 2&3:\nI. Make :/string actually match the RE ^[/]*string, and ://string a full path.\n The leading [/]* is a very small change to get_sha1_oneline().\n [Or change prefixcmp() to strstr() in get_sha1_oneline().]\n How often do commit messages start with / ?\nII. Make :/string a full path, and ://string match ^string .\n Is changing the current :/string to ://string less painful/dangerous?\nIII. Make :/string match ^string when string has no slashes,\n :/string a full path when string does have slashes,\n and ://string match ^string . Hmm, seems confusing.\nDo you use :/string now? Since it's a case-sensitive exact match,\nI don't think I'd even use it.\nI find idea (II) most natural: absolute paths have one /,\nand string matches have 2 suggesting an RE.\n\nConcerning the current :string , perhaps we could do the following.\nThere would be 2 internal fixed mode variables (NOT config variables) which\ndo the following. The first controls whether this means an absolute\nor relative path. The second controls whether a warning message\nis printed whenever the first is consulted to make a decision. The\ninterpretation of :string is left as-is, but motivated janitors (like me\nin this case) can use the second mode variable to change all\n:string patterns to :/string or ://string in scripts, letting us\nswitch over later\nby changing one mode variable.\n\nSomeone mentioned DWIM for :string -- check both absolute and relative,\nin that order for compatibility probably. This seems a messy\ndefinition to me. Comments?\n\nAnyway, this is more involved than I'd hoped,\nbut it's good to think about consequences.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41067","messageId":"81b0412b0705041017l1ceb419j733e9cf3389e9709@mail.gmail.com","threadId":"7967","inReplyTo":"56b7f5510705040957v4580b6c1xbe767892ada3bcde@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T17:17:32Z","receivedAt":"2007-05-04T17:17:32Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/4/07, Dana How wrote:\n> > > This all depends on deciding that :relpath should be the (incompatible)\n> > > new default, and I'm not sure that's going to happen.\n> >\n> > If we are to stay that compatible, maybe \":./\" for relative paths and the\n> > old syntax left to mean top-level would the best choice for now.\n>\n> Let's summarize so far: I think everyone's convinced me we need\n> to be careful, so this email will be more tedious than I'd like.\n>\n> (a) :./relpath clearly inidicates relative path. [Also take :../relpath .]\n\nAck\n\n> (b) I'd like a more natural way to do :./relpath (e.g. :relpath),\n> or at least a future path to such.\n> (c) We would like to avoid new special characters beyond \":\".\n> This means everything has to be done with \".\" and \"/\".\n\nAnd new semantics, if possible\n\n> (d) We are left with the following patterns:\n> 1. :string\n\nProbably breaks something\n\n> 2. :/string\n\nTaken\n\n> 3. ://string\n\nUgly (and breaks tab completion)\n\n> [ We need a clear way to say relative, a clear way to say absolute,\n> and the current :string can change from absolute to relative some time\n> in the future if we so decide. ]\n>\n> Ideas for (d) 2&3:\n> I. Make :/string actually match the RE ^[/]*string, and ://string a full path.\n> The leading [/]* is a very small change to get_sha1_oneline().\n> [Or change prefixcmp() to strstr() in get_sha1_oneline().]\n> How often do commit messages start with / ?\n\nHow often should they start to justify any decision?\n\n> II. Make :/string a full path, and ://string match ^string .\n> Is changing the current :/string to ://string less painful/dangerous?\n\nJohannes?\n\n> III. Make :/string match ^string when string has no slashes,\n> :/string a full path when string does have slashes,\n> and ://string match ^string . Hmm, seems confusing.\n\nVery/\n\n> Do you use :/string now? Since it's a case-sensitive exact match,\n\nNo. It just exists, AFAICS\n\n> I don't think I'd even use it.\n> I find idea (II) most natural: absolute paths have one /,\n> and string matches have 2 suggesting an RE.\n\nI think, I'd be convinced by this one too, if not for \"//\" making\nno sense anywhere but root accidentally typed twice.\nI'd even sacrifice (or change) the search syntax for good.\n"},{"id":"41068","messageId":"7vabwktsng.fsf@assigned-by-dhcp.cox.net","threadId":"7967","inReplyTo":"463AFAAE.853DEF7B@eudaptics.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-04T17:17:39Z","receivedAt":"2007-05-04T17:17:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Alex Riesen wrote:\n>> On 5/4/07, Junio C Hamano wrote:\n>> > My preference is (2), (3) and then (1), but I do not have\n>> > offhand a suggestion for a good metacharacter we could use.\n>> \n>> \"./\" :)\n>\n> +1, without the :)\n> and ../ should DWIM, too.\n\nI think these feel more or less natural (except that we do not\nsay \":/fullpath\" and instead say \":fullpath\" which is\nunfortunate).\n\nIn the hindsight, if we had the perfect vision into the future,\nwe would have made relative to where you are when we\ninitially did \":\", with obvious semantics for\nthings like \":../\" and \":/\".\n\nWe didn't. Further, we made a mistake to make :/ to mean\nsomething completely unrelated. My bad.\n\nSo I think \"./\" is the best compromise in the meantime.\n\nWith your suggestion, we can train people's fingers to type \"./\"\nnow, and perhaps later in one of those big feature release like\nthe 1.5.0 was, we could switch to \"default to relative\".\n\nAt the same time of that big \"UI correction\", we could make\n\":/\" to mean \"full path in commit (or\nindex/stage) no matter where I am\".\n\nThe current \":/\" is about going back, looking for the\nstring, so it should not have used '/'; instead it should have\nbeen \":?\". Maybe we could fix it by start\naccepting \":?\" now (in addition to \":/\"), give a big fat warning\nabout \":/\" going to mean a different thing, and encouraging\nusers to use the question-mark form, in preparation for the big\n\"UI correction\".\n\nDo people like that plan?\n\n(soon after 1.5.2)\n\n - start accepting \":./\" as \"relative to where I am\".\n\n - start accepting \":?\" as \"look back to find\n the string\".\n\n - clearly explain the plan and prepare the users.\n\n(a big release in the future, perhaps 1.6.0)\n\n - \":\" becomes relative to where you are.\n - stop \":/\" and start \":/\".\n"},{"id":"41072","messageId":"56b7f5510705041123h7fc1f95djbf7c2d75466b4193@mail.gmail.com","threadId":"7967","inReplyTo":"7vabwktsng.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-04T18:23:21Z","receivedAt":"2007-05-04T18:23:21Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/4/07, Junio C Hamano wrote:\n> Johannes Sixt writes:\n>\n> > Alex Riesen wrote:\n> >> On 5/4/07, Junio C Hamano wrote:\n> >> > My preference is (2), (3) and then (1), but I do not have\n> >> > offhand a suggestion for a good metacharacter we could use.\n> >>\n> >> \"./\" :)\n> >\n> > +1, without the :)\n> > and ../ should DWIM, too.\n>\n> I think these feel more or less natural (except that we do not\n> say \":/fullpath\" and instead say \":fullpath\" which is\n> unfortunate).\n>\n> In the hindsight, if we had the perfect vision into the future,\n> we would have made relative to where you are when we\n> initially did \":\", with obvious semantics for\n> things like \":../\" and \":/\".\n>\n> We didn't. Further, we made a mistake to make :/ to mean\n> something completely unrelated. My bad.\n>\n> So I think \"./\" is the best compromise in the meantime.\n>\n> With your suggestion, we can train people's fingers to type \"./\"\n> now, and perhaps later in one of those big feature release like\n> the 1.5.0 was, we could switch to \"default to relative\".\n>\n> At the same time of that big \"UI correction\", we could make\n> \":/\" to mean \"full path in commit (or\n> index/stage) no matter where I am\".\n>\n> The current \":/\" is about going back, looking for the\n> string, so it should not have used '/'; instead it should have\n> been \":?\". Maybe we could fix it by start\n> accepting \":?\" now (in addition to \":/\"), give a big fat warning\n> about \":/\" going to mean a different thing, and encouraging\n> users to use the question-mark form, in preparation for the big\n> \"UI correction\".\n>\n> Do people like that plan?\n>\n> (soon after 1.5.2)\n>\n> - start accepting \":./\" as \"relative to where I am\".\n>\n> - start accepting \":?\" as \"look back to find\n> the string\".\n>\n> - clearly explain the plan and prepare the users.\n>\n> (a big release in the future, perhaps 1.6.0)\n>\n> - \":\" becomes relative to where you are.\n> - stop \":/\" and start \":/\".\n\nI will resubmit the patch following Junio's plan.\nIt will include the \"1.6.0\" features but disabled.\n\nI would just request that we expedite, if possible,\nat least the later switch from \":/\"\nto \":/\",\nsince with the patch _and_ the latter behavior enabled,\nscripts can be updated to always insert \"./\" or \"/\" and\ntheir intent will always be clear.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41075","messageId":"Pine.LNX.4.64.0705042025130.4015@racer.site","threadId":"7967","inReplyTo":"81b0412b0705041017l1ceb419j733e9cf3389e9709@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-04T19:00:53Z","receivedAt":"2007-05-04T19:00:53Z","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, Alex Riesen wrote:\n\n> On 5/4/07, Dana How wrote:\n>\n> > II. Make :/string a full path, and ://string match ^string .\n> > Is changing the current :/string to ://string less painful/dangerous?\n> \n> Johannes?\n\nHuh? Hello!\n\nI did not follow this thread closely...\n\nHaving said that, I think \":./bla/blub\" is the most intuitive, and the \nleast breaking.\n\nYou _could_ change the current :/ notation, but _why_?\n\nCiao,\nDscho\n"},{"id":"41076","messageId":"Pine.LNX.4.64.0705042104370.4015@racer.site","threadId":"7967","inReplyTo":"7vabwktsng.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-04T19:06:30Z","receivedAt":"2007-05-04T19:06:30Z","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, Junio C Hamano wrote:\n\n> (a big release in the future, perhaps 1.6.0)\n> \n> - \":\" becomes relative to where you are.\n\nFWIW I still find that unintuitive. I know \":\" from ssh, \nand there it does not change meaning depending on where I am. IMHO in most \ncases you want to use git-diff anyway, which _does_ honour the current \nrelative path.\n\nCiao,\nDscho\n"},{"id":"41078","messageId":"7v1whwtmvj.fsf@assigned-by-dhcp.cox.net","threadId":"7967","inReplyTo":"Pine.LNX.4.64.0705042104370.4015@racer.site","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-04T19:22:24Z","receivedAt":"2007-05-04T19:22:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> FWIW I still find that unintuitive. I know \":\" from ssh, \n> and there it does not change meaning depending on where I am. IMHO in most \n> cases you want to use git-diff anyway, which _does_ honour the current \n> relative path.\n\nThere, its meaning is relative to where you are, namely \"$HOME\".\n"},{"id":"41079","messageId":"Pine.LNX.4.64.0705042127390.4015@racer.site","threadId":"7967","inReplyTo":"7v1whwtmvj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-04T19:31:42Z","receivedAt":"2007-05-04T19:31:42Z","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, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > FWIW I still find that unintuitive. I know \":\" from ssh, \n> > and there it does not change meaning depending on where I am. IMHO in most \n> > cases you want to use git-diff anyway, which _does_ honour the current \n> > relative path.\n> \n> There, its meaning is relative to where you are, namely \"$HOME\".\n\nNo, it is relative to where I am _at the other end_. If I \"cd /tmp\", it \nstill is relative to $HOME.\n\nNow, what you want to do is changing the meaning of v1.5.1:Makefile, \ndepending if you \"cd Documentation/\"ed or not.\n\nFor me, \"v1.5.1:\" means something similar to ssh: it is a distant \nrevision. It is not a complete filesystem. I think of revisions as \nsomething more general than a directory, but less general than a \nfilesystem. And thus, it makes perfect sense to me that \"v1.5.1:Makefile\" \nmeans the main Makefile, no matter where I am in the current repository.\n\nNow, I agree that often you want to compare some file in the current \ndirectory to the corresponding file in a certain revision. That is why \ngit-diff has a different idea, and indeed, a different notation, too.\n\nCiao,\nDscho\n"},{"id":"41080","messageId":"7vwszos7l2.fsf@assigned-by-dhcp.cox.net","threadId":"7967","inReplyTo":"Pine.LNX.4.64.0705042127390.4015@racer.site","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-04T19:38:01Z","receivedAt":"2007-05-04T19:38:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> For me, \"v1.5.1:\" means something similar to ssh: it is a distant \n> revision. It is not a complete filesystem. I think of revisions as \n> something more general than a directory, but less general than a \n> filesystem. And thus, it makes perfect sense to me that \"v1.5.1:Makefile\" \n> means the main Makefile, no matter where I am in the current repository.\n\nI see merits in both sides' arguments. \n\nSaying \"path out of THIS version\" anchors your mindset at the\ntop of that version, so in that sense v1.5.1:Makefile should\nmean the toplevel no matter where you are. However...\n\n> Now, I agree that often you want to compare some file in the current \n> directory to the corresponding file in a certain revision. That is why \n> git-diff has a different idea, and indeed, a different notation, too.\n\n... don't you expect \"git show HEAD@{yesterday}:git.txt\" while\nin Documentation/ subdirectory to work? I wonder if the current\nalternative \"git show HEAD@{yesterday}:Documentation/git.txt\" a\nbit unintuitive.\n"},{"id":"41082","messageId":"Pine.LNX.4.64.0705042140430.4015@racer.site","threadId":"7967","inReplyTo":"7vwszos7l2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-04T19:42:50Z","receivedAt":"2007-05-04T19:42:50Z","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, Junio C Hamano wrote:\n\n> ... don't you expect \"git show HEAD@{yesterday}:git.txt\" while\n> in Documentation/ subdirectory to work?\n\nActually, no. I expect \"git diff HEAD@{yesterday} git.txt\" to work fine, \nand \"git show HEAD@{yesterday}:git.c\" also, both when in Documentation/, \nbecause I expect \"git show HEAD@{yesterday}:git.c\" to work _also_ when I \nset GIT_DIR=/path/to/my/bare-repo.git/ before that, while I do not expect \nthe call to git-diff to work (for obvious reasons).\n\nCiao,\nDscho\n"},{"id":"41085","messageId":"20070504202143.GA4033@steel.home","threadId":"7967","inReplyTo":"7vabwktsng.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T20:21:43Z","receivedAt":"2007-05-04T20:21:43Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Fri, May 04, 2007 19:17:39 +0200:\n> Do people like that plan?\n> \n> (soon after 1.5.2)\n> \n> - start accepting \":./\" as \"relative to where I am\".\n> \n> - start accepting \":?\" as \"look back to find\n> the string\".\n\nStill don't like the feature. It makes things special: suddenly we\nhave to be careful about not having files with a \"?\" as their first\nsymbol (well, scripts always can prepend \"./\" or \"/\")\n\nAnd it is hard to use: only prefix, must be unambiguous and is\ncase sensitive.\n\n> - clearly explain the plan and prepare the users.\n> \n> (a big release in the future, perhaps 1.6.0)\n> \n> - \":\" becomes relative to where you are.\n> - stop \":/\" and start \":/\".\n\nI like the plan.\n"},{"id":"41086","messageId":"20070504202324.GB4033@steel.home","threadId":"7967","inReplyTo":"Pine.LNX.4.64.0705042025130.4015@racer.site","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-04T20:23:24Z","receivedAt":"2007-05-04T20:23:24Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Fri, May 04, 2007 21:00:53 +0200:\n> Having said that, I think \":./bla/blub\" is the most intuitive, and the \n> least breaking.\n> \n> You _could_ change the current :/ notation, but _why_?\n\nTo use the syntax for full path starting from root of repo.\nIt looks \"most intuitive\" for this.\n"},{"id":"41104","messageId":"f1gg1o$p52$2@sea.gmane.org","threadId":"7967","inReplyTo":"7vabwktsng.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-04T23:36:21Z","receivedAt":"2007-05-04T23:36:21Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> (soon after 1.5.2)\n> \n>  - start accepting \":./\" as \"relative to where I am\".\n>  - start accepting \":?\" as \"look back to find\n>    the string\".\n>  - clearly explain the plan and prepare the users.\n> \n> (a big release in the future, perhaps 1.6.0)\n> \n>  - \":\" becomes relative to where you are.\n>  - stop \":/\" and start \":/\".\n\nI'm not sure about \":\" with being relative by\ndefault. For me it is in (like in \n\"git-ls-tree -r \" result).\n\nThe \":./\" is a good syntax I think.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"41106","messageId":"7vy7k4p24s.fsf@assigned-by-dhcp.cox.net","threadId":"7967","inReplyTo":"f1gg1o$p52$2@sea.gmane.org","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-05T00:04:03Z","receivedAt":"2007-05-05T00:04:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> I'm not sure about \":\" with being relative by\n> default. For me it is in (like in \n> \"git-ls-tree -r \" result).\n\nThat's right (and Dscho is also).\n\n\"v1.5.1:git.c\" IS \"git.c that appears at the toplevel of\nv1.5.1's tree.\"\n\nOk, for now let's forget about this relative stuff.\n"},{"id":"41108","messageId":"56b7f5510705041752o74b59284x872480e4413f83ab@mail.gmail.com","threadId":"7967","inReplyTo":"7vy7k4p24s.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-05T00:52:38Z","receivedAt":"2007-05-05T00:52:38Z","isPatch":true,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/4/07, Junio C Hamano wrote:\n> Jakub Narebski writes:\n> > I'm not sure about \":\" with being relative by\n> > default. For me it is in (like in\n> > \"git-ls-tree -r \" result).\n>\n> That's right (and Dscho is also).\n>\n> \"v1.5.1:git.c\" IS \"git.c that appears at the toplevel of\n> v1.5.1's tree.\"\n>\n> Ok, for now let's forget about this relative stuff.\n\nHmm, most of the work I do in the parts of our\nperforce repository I want to convert to git is\nfar enough down that the paths have 6 in-repo path components.\nI don't want to type all those when I want to fetch an\nolder version with git-show. Everything I do is relative.\nIn fact, I think perforce supports typing absolute paths,\n(using an 8-character prefix!) but I have never used it,\nnor would I if it were shorter.\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41109","messageId":"200705050306.32345.jnareb@gmail.com","threadId":"7967","inReplyTo":"56b7f5510705041752o74b59284x872480e4413f83ab@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-05T01:06:31Z","receivedAt":"2007-05-05T01:06:31Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dana How wrote:\n> On 5/4/07, Junio C Hamano wrote:\n>> Jakub Narebski writes:\n\n>>> I'm not sure about \":\" with being relative by\n>>> default. For me it is in (like in\n>>> \"git-ls-tree -r \" result).\n>>\n>> That's right (and Dscho is also).\n>>\n>> \"v1.5.1:git.c\" IS \"git.c that appears at the toplevel of\n>> v1.5.1's tree.\"\n>>\n>> Ok, for now let's forget about this relative stuff.\n> \n> Hmm, most of the work I do in the parts of our\n> perforce repository I want to convert to git is\n> far enough down that the paths have 6 in-repo path components.\n> I don't want to type all those when I want to fetch an\n> older version with git-show. Everything I do is relative.\n> In fact, I think perforce supports typing absolute paths,\n> (using an 8-character prefix!) but I have never used it,\n> nor would I if it were shorter.\n\nI think the consensus is to use :./ for \nrelative paths, and : for absolute (well, in the \nmeaning that it counts from top of _tree-ish_, and tree-ish needs\nnot to be top tree / commit tree).\n\nAnd I think 6 in-repo path components means not very well thought \ndirectory hierarchy, I think...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"41111","messageId":"7vtzusoyty.fsf@assigned-by-dhcp.cox.net","threadId":"7967","inReplyTo":"56b7f5510705041752o74b59284x872480e4413f83ab@mail.gmail.com","subject":"Re: [PATCH] Support ent:relative_path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-05T01:15:21Z","receivedAt":"2007-05-05T01:15:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Dana How\" writes:\n\n> On 5/4/07, Junio C Hamano wrote:\n>> Jakub Narebski writes:\n>> > I'm not sure about \":\" with being relative by\n>> > default. For me it is in (like in\n>> > \"git-ls-tree -r \" result).\n>>\n>> That's right (and Dscho is also).\n>>\n>> \"v1.5.1:git.c\" IS \"git.c that appears at the toplevel of\n>> v1.5.1's tree.\"\n>>\n>> Ok, for now let's forget about this relative stuff.\n>\n> Hmm, most of the work I do in the parts of our\n> perforce repository I want to convert to git is\n> far enough down...\n\nThe key word in my statement is \"for now\". I simply declared\nthat I do not want to think about it further until 1.5.2 final,\nthat's all.\n\nI am not opposed to give an escape hatch for your problem; I am\nquite in favor of that, and I think Alex/J6t's \"./\" syntax is a\nreasonable compromise.\n"}]}