{"thread":{"id":"38071","subject":"[PATCH] introduce git root","startedAt":"2014-11-29T20:00:11Z","lastAt":"2014-12-10T21:08:57Z","messageCount":23,"participants":["Arjun Sreedharan","Philip Oakley","Matthieu Moy","Junio C Hamano","Christian Couder","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"252675","messageId":"1417291211-32268-1-git-send-email-arjun024@gmail.com","threadId":"38071","inReplyTo":null,"subject":"[PATCH] introduce git root","fromName":"Arjun Sreedharan","fromEmail":"arjun024@gmail.com","sentAt":"2014-11-29T20:00:11Z","receivedAt":"2014-11-29T20:00:11Z","isPatch":true,"sender":{"key":"arjun024@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2861611?v=4"},"body":"This introduces `git root` which outputs the root directory\n(the directory that contains .git).\nThe same can be accomplished by `git rev-parse --show-toplevel`.\n`git root` is much more intuitive and easy to remember.\nAll it does is set the arguments for rev-parse\n\nSigned-off-by: Arjun Sreedharan <arjun024@gmail.com>\n---\n\n\nHi,\nI don't know if I can just send a patch for a new \"command\" in git,\nI probably shouldn't. Well, i thought it's anyway better explaining\nthis way than just asking for comments.\n\nWith the kind of projects i have been involved with in the recent past, I\nhave had to deal with subprojects inside projects and for many reasons had\nto find ways to find the root git folder and at times to \"cd\" to it.\n\nThe obvious choice is to go for `git rev-parse --show-toplevel`. But, this\nto me doesn't seem very _intuitive_ and `git root` does.\nbzr has `bzr root`. hg has `hg root`. So, for programmers i am guessing\nthis pattern would also be _instinctive_, and i am thinking why not `git root`?\nArjun Sreedharan\n\n\n\n Makefile       |  1 +\n builtin.h      |  1 +\n builtin/root.c | 10 ++++++++++\n git.c          |  1 +\n 4 files changed, 13 insertions(+)\n create mode 100644 builtin/root.c\n\ndiff --git a/Makefile b/Makefile\nindex 827006b..7f28d13 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -869,6 +869,7 @@ BUILTIN_OBJS += builtin/rev-list.o\n BUILTIN_OBJS += builtin/rev-parse.o\n BUILTIN_OBJS += builtin/revert.o\n BUILTIN_OBJS += builtin/rm.o\n+BUILTIN_OBJS += builtin/root.o\n BUILTIN_OBJS += builtin/send-pack.o\n BUILTIN_OBJS += builtin/shortlog.o\n BUILTIN_OBJS += builtin/show-branch.o\ndiff --git a/builtin.h b/builtin.h\nindex b87df70..4672d72 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -112,6 +112,7 @@ extern int cmd_rev_list(int argc, const char **argv, const char *prefix);\n extern int cmd_rev_parse(int argc, const char **argv, const char *prefix);\n extern int cmd_revert(int argc, const char **argv, const char *prefix);\n extern int cmd_rm(int argc, const char **argv, const char *prefix);\n+extern int cmd_root(int argc, const char **argv, const char *prefix);\n extern int cmd_send_pack(int argc, const char **argv, const char *prefix);\n extern int cmd_shortlog(int argc, const char **argv, const char *prefix);\n extern int cmd_show(int argc, const char **argv, const char *prefix);\ndiff --git a/builtin/root.c b/builtin/root.c\nnew file mode 100644\nindex 0000000..c2eeca3\n--- /dev/null\n+++ b/builtin/root.c\n@@ -0,0 +1,10 @@\n+#include \"builtin.h\"\n+#include \"argv-array.h\"\n+\n+int cmd_root(int argc, const char **argv, const char *prefix)\n+{\n+\tstruct argv_array root_args = ARGV_ARRAY_INIT;\n+\n+\targv_array_pushl(&root_args, argv[0], \"--show-toplevel\", NULL);\n+\treturn cmd_rev_parse(root_args.argc, root_args.argv, prefix);\n+}\ndiff --git a/git.c b/git.c\nindex 18fbf79..6a0be5f 100644\n--- a/git.c\n+++ b/git.c\n@@ -461,6 +461,7 @@ static struct cmd_struct commands[] = {\n \t{ \"rev-parse\", cmd_rev_parse },\n \t{ \"revert\", cmd_revert, RUN_SETUP | NEED_WORK_TREE },\n \t{ \"rm\", cmd_rm, RUN_SETUP },\n+\t{ \"root\", cmd_root, RUN_SETUP },\n \t{ \"send-pack\", cmd_send_pack, RUN_SETUP },\n \t{ \"shortlog\", cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER },\n \t{ \"show\", cmd_show, RUN_SETUP },\n-- \n1.7.11.7\n"},{"id":"252676","messageId":"2AC7B765F56B4AA8A0DB76E8C670A889@PhilipOakley","threadId":"38071","inReplyTo":"1417291211-32268-1-git-send-email-arjun024@gmail.com","subject":"Re: [PATCH] introduce git root","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2014-11-29T20:00:11Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Arjun Sreedharan\" <arjun024@gmail.com>\n> This introduces `git root` which outputs the root directory\n> (the directory that contains .git).\n> The same can be accomplished by `git rev-parse --show-toplevel`.\n> `git root` is much more intuitive and easy to remember.\n> All it does is set the arguments for rev-parse\n\nThis may be better as an alias.\nI've added it to my aliases list.\n\n>\n> Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>\n> ---\n>\n>\n> Hi,\n> I don't know if I can just send a patch for a new \"command\" in git,\n> I probably shouldn't. Well, i thought it's anyway better explaining\n> this way than just asking for comments.\n>\n> With the kind of projects i have been involved with in the recent \n> past, I\n> have had to deal with subprojects inside projects and for many reasons \n> had\n> to find ways to find the root git folder and at times to \"cd\" to it.\n>\n> The obvious choice is to go for `git rev-parse --show-toplevel`. But, \n> this\n> to me doesn't seem very _intuitive_ and `git root` does.\n> bzr has `bzr root`. hg has `hg root`. So, for programmers i am \n> guessing\n> this pattern would also be _instinctive_, and i am thinking why not \n> `git root`?\n> Arjun Sreedharan\n>\n>\n>\n> Makefile       |  1 +\n> builtin.h      |  1 +\n> builtin/root.c | 10 ++++++++++\n> git.c          |  1 +\n> 4 files changed, 13 insertions(+)\n> create mode 100644 builtin/root.c\n>\n> diff --git a/Makefile b/Makefile\n> index 827006b..7f28d13 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -869,6 +869,7 @@ BUILTIN_OBJS += builtin/rev-list.o\n> BUILTIN_OBJS += builtin/rev-parse.o\n> BUILTIN_OBJS += builtin/revert.o\n> BUILTIN_OBJS += builtin/rm.o\n> +BUILTIN_OBJS += builtin/root.o\n> BUILTIN_OBJS += builtin/send-pack.o\n> BUILTIN_OBJS += builtin/shortlog.o\n> BUILTIN_OBJS += builtin/show-branch.o\n> diff --git a/builtin.h b/builtin.h\n> index b87df70..4672d72 100644\n> --- a/builtin.h\n> +++ b/builtin.h\n> @@ -112,6 +112,7 @@ extern int cmd_rev_list(int argc, const char \n> **argv, const char *prefix);\n> extern int cmd_rev_parse(int argc, const char **argv, const char \n> *prefix);\n> extern int cmd_revert(int argc, const char **argv, const char \n> *prefix);\n> extern int cmd_rm(int argc, const char **argv, const char *prefix);\n> +extern int cmd_root(int argc, const char **argv, const char *prefix);\n> extern int cmd_send_pack(int argc, const char **argv, const char \n> *prefix);\n> extern int cmd_shortlog(int argc, const char **argv, const char \n> *prefix);\n> extern int cmd_show(int argc, const char **argv, const char *prefix);\n> diff --git a/builtin/root.c b/builtin/root.c\n> new file mode 100644\n> index 0000000..c2eeca3\n> --- /dev/null\n> +++ b/builtin/root.c\n> @@ -0,0 +1,10 @@\n> +#include \"builtin.h\"\n> +#include \"argv-array.h\"\n> +\n> +int cmd_root(int argc, const char **argv, const char *prefix)\n> +{\n> + struct argv_array root_args = ARGV_ARRAY_INIT;\n> +\n> + argv_array_pushl(&root_args, argv[0], \"--show-toplevel\", NULL);\n> + return cmd_rev_parse(root_args.argc, root_args.argv, prefix);\n> +}\n> diff --git a/git.c b/git.c\n> index 18fbf79..6a0be5f 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -461,6 +461,7 @@ static struct cmd_struct commands[] = {\n>  { \"rev-parse\", cmd_rev_parse },\n>  { \"revert\", cmd_revert, RUN_SETUP | NEED_WORK_TREE },\n>  { \"rm\", cmd_rm, RUN_SETUP },\n> + { \"root\", cmd_root, RUN_SETUP },\n>  { \"send-pack\", cmd_send_pack, RUN_SETUP },\n>  { \"shortlog\", cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER },\n>  { \"show\", cmd_show, RUN_SETUP },\n> -- \n> 1.7.11.7\n>\n> --\nPhilip \n"},{"id":"252682","messageId":"CAJFMrCEciWXhBb36MVeFPi7Y7D=9zQ2xGPpiyUz9y4_hOh_taw@mail.gmail.com","threadId":"38071","inReplyTo":"2AC7B765F56B4AA8A0DB76E8C670A889@PhilipOakley","subject":"Re: [PATCH] introduce git root","fromName":"Arjun Sreedharan","fromEmail":"arjun024@gmail.com","sentAt":"2014-11-30T04:35:37Z","receivedAt":"2014-11-30T04:35:37Z","isPatch":true,"sender":{"key":"arjun024@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2861611?v=4"},"body":"On 30 November 2014 at 04:38, Philip Oakley <philipoakley@iee.org> wrote:\n> From: \"Arjun Sreedharan\" <arjun024@gmail.com>\n>>\n>> This introduces `git root` which outputs the root directory\n>> (the directory that contains .git).\n>> The same can be accomplished by `git rev-parse --show-toplevel`.\n>> `git root` is much more intuitive and easy to remember.\n>> All it does is set the arguments for rev-parse\n>\n>\n> This may be better as an alias.\n> I've added it to my aliases list.\n>\n\nI know that. I am suggesting this to be a built-in command, without having the\nneed to add as an alias.\n\n>>\n>> Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>\n>> ---\n>>\n>>\n>> Hi,\n>> I don't know if I can just send a patch for a new \"command\" in git,\n>> I probably shouldn't. Well, i thought it's anyway better explaining\n>> this way than just asking for comments.\n>>\n>> With the kind of projects i have been involved with in the recent past, I\n>> have had to deal with subprojects inside projects and for many reasons had\n>> to find ways to find the root git folder and at times to \"cd\" to it.\n>>\n>> The obvious choice is to go for `git rev-parse --show-toplevel`. But, this\n>> to me doesn't seem very _intuitive_ and `git root` does.\n>> bzr has `bzr root`. hg has `hg root`. So, for programmers i am guessing\n>> this pattern would also be _instinctive_, and i am thinking why not `git\n>> root`?\n>> Arjun Sreedharan\n>>\n>>\n>>\n>> Makefile       |  1 +\n>> builtin.h      |  1 +\n>> builtin/root.c | 10 ++++++++++\n>> git.c          |  1 +\n>> 4 files changed, 13 insertions(+)\n>> create mode 100644 builtin/root.c\n>>\n>> diff --git a/Makefile b/Makefile\n>> index 827006b..7f28d13 100644\n>> --- a/Makefile\n>> +++ b/Makefile\n>> @@ -869,6 +869,7 @@ BUILTIN_OBJS += builtin/rev-list.o\n>> BUILTIN_OBJS += builtin/rev-parse.o\n>> BUILTIN_OBJS += builtin/revert.o\n>> BUILTIN_OBJS += builtin/rm.o\n>> +BUILTIN_OBJS += builtin/root.o\n>> BUILTIN_OBJS += builtin/send-pack.o\n>> BUILTIN_OBJS += builtin/shortlog.o\n>> BUILTIN_OBJS += builtin/show-branch.o\n>> diff --git a/builtin.h b/builtin.h\n>> index b87df70..4672d72 100644\n>> --- a/builtin.h\n>> +++ b/builtin.h\n>> @@ -112,6 +112,7 @@ extern int cmd_rev_list(int argc, const char **argv,\n>> const char *prefix);\n>> extern int cmd_rev_parse(int argc, const char **argv, const char *prefix);\n>> extern int cmd_revert(int argc, const char **argv, const char *prefix);\n>> extern int cmd_rm(int argc, const char **argv, const char *prefix);\n>> +extern int cmd_root(int argc, const char **argv, const char *prefix);\n>> extern int cmd_send_pack(int argc, const char **argv, const char *prefix);\n>> extern int cmd_shortlog(int argc, const char **argv, const char *prefix);\n>> extern int cmd_show(int argc, const char **argv, const char *prefix);\n>> diff --git a/builtin/root.c b/builtin/root.c\n>> new file mode 100644\n>> index 0000000..c2eeca3\n>> --- /dev/null\n>> +++ b/builtin/root.c\n>> @@ -0,0 +1,10 @@\n>> +#include \"builtin.h\"\n>> +#include \"argv-array.h\"\n>> +\n>> +int cmd_root(int argc, const char **argv, const char *prefix)\n>> +{\n>> + struct argv_array root_args = ARGV_ARRAY_INIT;\n>> +\n>> + argv_array_pushl(&root_args, argv[0], \"--show-toplevel\", NULL);\n>> + return cmd_rev_parse(root_args.argc, root_args.argv, prefix);\n>> +}\n>> diff --git a/git.c b/git.c\n>> index 18fbf79..6a0be5f 100644\n>> --- a/git.c\n>> +++ b/git.c\n>> @@ -461,6 +461,7 @@ static struct cmd_struct commands[] = {\n>>  { \"rev-parse\", cmd_rev_parse },\n>>  { \"revert\", cmd_revert, RUN_SETUP | NEED_WORK_TREE },\n>>  { \"rm\", cmd_rm, RUN_SETUP },\n>> + { \"root\", cmd_root, RUN_SETUP },\n>>  { \"send-pack\", cmd_send_pack, RUN_SETUP },\n>>  { \"shortlog\", cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER },\n>>  { \"show\", cmd_show, RUN_SETUP },\n>> --\n>> 1.7.11.7\n>>\n>> --\n>\n> Philip\n"},{"id":"252743","messageId":"vpqoaro99xd.fsf@anie.imag.fr","threadId":"38071","inReplyTo":"CAJFMrCEciWXhBb36MVeFPi7Y7D=9zQ2xGPpiyUz9y4_hOh_taw@mail.gmail.com","subject":"Re: [PATCH] introduce git root","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-11-30T11:58:54Z","receivedAt":"2014-11-30T11:58:54Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Arjun Sreedharan <arjun024@gmail.com> writes:\n\n> On 30 November 2014 at 04:38, Philip Oakley <philipoakley@iee.org> wrote:\n>> From: \"Arjun Sreedharan\" <arjun024@gmail.com>\n>>>\n>>> This introduces `git root` which outputs the root directory\n>>> (the directory that contains .git).\n>>> The same can be accomplished by `git rev-parse --show-toplevel`.\n>>> `git root` is much more intuitive and easy to remember.\n>>> All it does is set the arguments for rev-parse\n>>\n>>\n>> This may be better as an alias.\n>> I've added it to my aliases list.\n>>\n>\n> I know that. I am suggesting this to be a built-in command, without having the\n> need to add as an alias.\n\nIndeed, suggesting people to add an alias does not solve the\ndiscoverability issue. git rev-parse --show-toplevel is not just long,\nit's just not the place where people would look for (it's neither about\nrevision nor about parsing, so clearly, \"rev-parse\" is not a good place\nto host the feature in the UI).\n\nIf we were to rewrite Git from scratch, then I would be all for having a\n\"git root\" command. Given that we already have rev-parse\n--show-toplevel, and that we'll have to keep it anyway for backward\ncompatibility, I'm a bit more hesitant (\"Git is hard to use because it\ndoesn't have enough commands\" is not a complain I hear so often ;-) ),\nbut still mostly positive.\n\nIf we go this way, then the documentation must be updated too. I think\nthe doc should still recommend \"git rev-parse --show-toplevel\" for\nscripting until Git versions implementing \"git root\" are widely deployed\nenough.\n\nAlso, there are other options of git rev-parse which should be dealt\nwith: at least --show-cdup (could be eg. \"git root --relative\") and\n--show-prefix, but probably also others from the \"Options for Files\" in\nthe man of git-rev-parse.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"252760","messageId":"xmqqd284rryz.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"vpqoaro99xd.fsf@anie.imag.fr","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-01T03:04:04Z","receivedAt":"2014-12-01T03:04:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> ... git rev-parse --show-toplevel is not just long,\n> it's just not the place where people would look for (it's neither about\n> revision nor about parsing, so clearly, \"rev-parse\" is not a good place\n> to host the feature in the UI).\n\nFor the record, \"rev-parse\" is not about revisions in the first\nplace.  It started purely as a helper to implement \"git log\" in\nterms of \"git rev-list\" piped to \"git diff-tree --stdin\", which\nrequires you to sift a command line argument list given to such\na scripted \"git log\" into those to be passed to \"rev-list\" (i.e.\nprimarily revision ranges) and those to be passed to \"diff-tree\"\n(i.e. primarily diff options and pathspecs).\n\nVarious subcommands \"rev-parse\" takes such as --show-git-dir were\nadded only because there wasn't any single best \"kitchen sink\"\ncommand to tuck such a small feature that do not deserve a\nstandalone command (e.g. \"git root\", which makes it sound as if the\ntop-level of the working tree is the most important thing in the\nworld, and adding other useful things such as --show-prefix to it,\nwhile it would make sense to have them there from the implementation\npoint of view, would be hard to justify against the connotation the\nword \"root\" gives us), and we happened to pick \"rev-parse\" as a\n\"kitchen sink\" place, which is not better or worse as anything else.\n\nIf I were redoing this today, I would probably nominate the \"git\"\npotty as such a \"kitchen synk\" command.  We have \"--man-path\" that\nshows the location of the manual pages, \"--exec-path[=path]\" that\neither shows or allows us to override the path to the subcommands,\nand \"--show-prefix\", \"--show-toplevel\", and friends may feel quite\nat home there.\n"},{"id":"252764","messageId":"CAP8UFD2jES1i+6zOt1gXqTWFy1UHu2GBwAisQktd_Ymbj9Db2g@mail.gmail.com","threadId":"38071","inReplyTo":"xmqqd284rryz.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] introduce git root","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-12-01T04:17:22Z","receivedAt":"2014-12-01T04:17:22Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> If I were redoing this today, I would probably nominate the \"git\"\n> potty as such a \"kitchen synk\" command.  We have \"--man-path\" that\n> shows the location of the manual pages, \"--exec-path[=path]\" that\n> either shows or allows us to override the path to the subcommands,\n> and \"--show-prefix\", \"--show-toplevel\", and friends may feel quite\n> at home there.\n\nI wonder if we could reuse \"git config\" which is already a \"kitchen\nsynk\" command to get/set a lot of parameters.\nMaybe we could dedicate a \"git\" or \"virtual\" or \"proc\" or \"sys\" (like\n/proc or /sys  in Linux) namespace for these special config parameters\nthat would not necessarily reflect something in the config file.\n\n\"git config git.man-path\" would be the same as \"git --man-path\".\n\"git config git.root\" would be the same as \"git rev-parse --show-toplevel\".\n\"git config git.exec-path mypath\" would allow us to override the path\nto the subcommands, probably by saving something in the config file.\n\nIf we wanted for example to try just once a special exec-path we could use:\n\ngit -c git.exec-path=/path/to/git-foo foo\n\nBest,\nChristian.\n"},{"id":"252765","messageId":"xmqqwq6cq8cr.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"CAP8UFD2jES1i+6zOt1gXqTWFy1UHu2GBwAisQktd_Ymbj9Db2g@mail.gmail.com","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-01T04:53:08Z","receivedAt":"2014-12-01T04:53:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <christian.couder@gmail.com> writes:\n\n> I wonder if we could reuse \"git config\" which is already a \"kitchen\n> synk\" command to get/set a lot of parameters.\n\nI doubt it makes much sense.\n\n * Things like toplevel and cdup are not even something you\n   configure.  It is where you are, the current state of you.\n   \"git config\" does not make any sense at all.\n\n * manpath and execpath and friends _might_ be something you may\n   want to configure, and teach relevant codepaths to pay attention\n   to the new configuration values.  But until that happens, it does\n   not make sense to have that information in \"git config\".  \"git\n   config\" does not show values that are not actually configured, so\n   it won't be a replacement for \"git --man-path\" for those who do\n   not have nonstandard place configured.\n\nSo...\n"},{"id":"252839","messageId":"20141202070415.GC1948@peff.net","threadId":"38071","inReplyTo":"CAP8UFD2jES1i+6zOt1gXqTWFy1UHu2GBwAisQktd_Ymbj9Db2g@mail.gmail.com","subject":"Re: [PATCH] introduce git root","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-02T07:04:15Z","receivedAt":"2014-12-02T07:04:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 01, 2014 at 05:17:22AM +0100, Christian Couder wrote:\n\n> On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> >\n> > If I were redoing this today, I would probably nominate the \"git\"\n> > potty as such a \"kitchen synk\" command.  We have \"--man-path\" that\n> > shows the location of the manual pages, \"--exec-path[=path]\" that\n> > either shows or allows us to override the path to the subcommands,\n> > and \"--show-prefix\", \"--show-toplevel\", and friends may feel quite\n> > at home there.\n> \n> I wonder if we could reuse \"git config\" which is already a \"kitchen\n> synk\" command to get/set a lot of parameters.\n> Maybe we could dedicate a \"git\" or \"virtual\" or \"proc\" or \"sys\" (like\n> /proc or /sys  in Linux) namespace for these special config parameters\n> that would not necessarily reflect something in the config file.\n> \n> \"git config git.man-path\" would be the same as \"git --man-path\".\n> \"git config git.root\" would be the same as \"git rev-parse --show-toplevel\".\n> \"git config git.exec-path mypath\" would allow us to override the path\n> to the subcommands, probably by saving something in the config file.\n\nWhat would:\n\n  git config git.root foo\n  git config git.root\n\noutput? No matter what the answer is, I do not relish the thought of\ntrying to explain it in the documentation. :)\n\nThere is also \"git var\", which is a catch-all for printing some deduced\nenvironmental defaults. I'd be just as happy to see it go away, though.\nHaving:\n\n  git --exec-path\n  git --toplevel\n  git --author-ident\n\nall work would make sense to me (I often get confused between \"git\n--foo\" and \"git rev-parse --foo\" when trying to get the exec-path and\ngit-dir). And I don't think it's too late to move in this direction.\nWe'd have to keep the old interfaces around, of course, but it would\nimmediately improve discoverability and consistency.\n\n-Peff\n"},{"id":"252847","messageId":"CAP8UFD2P+GZ7Da+YcmjtYiYsESt+BdWc006NN6ps_X_n-We4iA@mail.gmail.com","threadId":"38071","inReplyTo":"20141202070415.GC1948@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-12-02T10:05:36Z","receivedAt":"2014-12-02T10:05:36Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Dec 2, 2014 at 8:04 AM, Jeff King <peff@peff.net> wrote:\n> On Mon, Dec 01, 2014 at 05:17:22AM +0100, Christian Couder wrote:\n>\n>> On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> >\n>> > If I were redoing this today, I would probably nominate the \"git\"\n>> > potty as such a \"kitchen synk\" command.  We have \"--man-path\" that\n>> > shows the location of the manual pages, \"--exec-path[=path]\" that\n>> > either shows or allows us to override the path to the subcommands,\n>> > and \"--show-prefix\", \"--show-toplevel\", and friends may feel quite\n>> > at home there.\n>>\n>> I wonder if we could reuse \"git config\" which is already a \"kitchen\n>> synk\" command to get/set a lot of parameters.\n>> Maybe we could dedicate a \"git\" or \"virtual\" or \"proc\" or \"sys\" (like\n>> /proc or /sys  in Linux) namespace for these special config parameters\n>> that would not necessarily reflect something in the config file.\n>>\n>> \"git config git.man-path\" would be the same as \"git --man-path\".\n>> \"git config git.root\" would be the same as \"git rev-parse --show-toplevel\".\n>> \"git config git.exec-path mypath\" would allow us to override the path\n>> to the subcommands, probably by saving something in the config file.\n>\n> What would:\n>\n>   git config git.root foo\n\nThat would output an error message saying that we cannot change the\ngit.root value.\n\n>   git config git.root\n\nThat would output the same as \"git rev-parse --show-toplevel\".\n\n> output? No matter what the answer is, I do not relish the thought of\n> trying to explain it in the documentation. :)\n\nYeah, maybe it is better if we don't reuse \"git config\".\n\n> There is also \"git var\", which is a catch-all for printing some deduced\n> environmental defaults. I'd be just as happy to see it go away, though.\n\nYeah, maybe we could use \"git var\" for more variables.\n\n> Having:\n>\n>   git --exec-path\n>   git --toplevel\n>   git --author-ident\n>\n> all work would make sense to me (I often get confused between \"git\n> --foo\" and \"git rev-parse --foo\" when trying to get the exec-path and\n> git-dir). And I don't think it's too late to move in this direction.\n> We'd have to keep the old interfaces around, of course, but it would\n> immediately improve discoverability and consistency.\n\nI don't like reusing the git command for that puropose, because it\nclutters it and makes it difficult to improve.\n\nFor example let's suppose that we decide to have a \"git info\" command.\nIt could work like this:\n\n$ git info sequence.editor\nvim\n\n$ git info core.editor\nemacs\n\n$ git info --verbose sequence.editor\nsequence.editor = vim\nGIT_EDITOR = emacs\ncore.editor = nano\n\n$ git info --verbose core.editor\nGIT_EDITOR = emacs\ncore.editor = nano\n\nSo the --verbose option could explain why the sequence.editor is vim\nby displaying the all the relevant options with their values from the\nmost important to the least important.\n\nBest,\nChristian.\n"},{"id":"252877","messageId":"xmqqd282m09j.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"20141202070415.GC1948@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-02T17:26:00Z","receivedAt":"2014-12-02T17:26:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> There is also \"git var\", which is a catch-all for printing some deduced\n> environmental defaults. I'd be just as happy to see it go away, though.\n> Having:\n>\n>   git --exec-path\n>   git --toplevel\n>   git --author-ident\n>\n> all work would make sense to me (I often get confused between \"git\n> --foo\" and \"git rev-parse --foo\" when trying to get the exec-path and\n> git-dir). And I don't think it's too late to move in this direction.\n> We'd have to keep the old interfaces around, of course, but it would\n> immediately improve discoverability and consistency.\n\nYeah, I too think the above makes sense.  I forgot about \"var\", but\nit should go at the same time we move kitchen-sink options out of\n\"rev-parse\".  One less command to worry about at the UI level means\nyou do not have to say \"if you want to learn about X, ask 'var', if\nyou want to learn about Y, ask 'rev-parse', use 'git' itself for Z\".\n"},{"id":"253045","messageId":"20141204092251.GC27455@peff.net","threadId":"38071","inReplyTo":"xmqqd282m09j.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] introduce git root","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-04T09:22:52Z","receivedAt":"2014-12-04T09:22:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > There is also \"git var\", which is a catch-all for printing some deduced\n> > environmental defaults. I'd be just as happy to see it go away, though.\n> > Having:\n> >\n> >   git --exec-path\n> >   git --toplevel\n> >   git --author-ident\n> >\n> > all work would make sense to me (I often get confused between \"git\n> > --foo\" and \"git rev-parse --foo\" when trying to get the exec-path and\n> > git-dir). And I don't think it's too late to move in this direction.\n> > We'd have to keep the old interfaces around, of course, but it would\n> > immediately improve discoverability and consistency.\n> \n> Yeah, I too think the above makes sense.  I forgot about \"var\", but\n> it should go at the same time we move kitchen-sink options out of\n> \"rev-parse\".  One less command to worry about at the UI level means\n> you do not have to say \"if you want to learn about X, ask 'var', if\n> you want to learn about Y, ask 'rev-parse', use 'git' itself for Z\".\n\nChristian raised the issue of cluttering the \"git --option\" namespace,\nand I do agree that's a potential issue. My proposal was to drop \"git\nvar\", but I'd also be OK with making \"git var\" the new kitchen sink.  It\ndoesn't accept many options now, so it's fairly wide open for changing\nwithout losing backwards compatibility. AFAICT, the \"-l\" option is\nutterly useless, but other than that, it just takes a variable name. We\ncould introduce dashed options, or just define a sane variable namespace.\n\nSome of the discussion has involved mixing config options into this\nkitchen sink, but that does not make any sense to me (and is why I find\n\"git var -l\" so odd). Config options are fundamentally different, in\nthat they are set and retrieved, not computed (from other config\nvariables, or from hard-coded values). And we already have a nice tool\nfor working with them (well...nice-ish, let's say).\n\n-Peff\n"},{"id":"253077","messageId":"xmqqlhmntf02.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"20141204092251.GC27455@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-04T19:02:37Z","receivedAt":"2014-12-04T19:02:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:\n>\n>> Jeff King <peff@peff.net> writes:\n>> \n>> > There is also \"git var\", which is a catch-all for printing some deduced\n>> > environmental defaults. I'd be just as happy to see it go away, though.\n>> > Having:\n>> >\n>> >   git --exec-path\n>> >   git --toplevel\n>> >   git --author-ident\n>> >\n>> > all work would make sense to me (I often get confused between \"git\n>> > --foo\" and \"git rev-parse --foo\" when trying to get the exec-path and\n>> > git-dir). And I don't think it's too late to move in this direction.\n>> > We'd have to keep the old interfaces around, of course, but it would\n>> > immediately improve discoverability and consistency.\n>> \n>> Yeah, I too think the above makes sense.  I forgot about \"var\", but\n>> it should go at the same time we move kitchen-sink options out of\n>> \"rev-parse\".  One less command to worry about at the UI level means\n>> you do not have to say \"if you want to learn about X, ask 'var', if\n>> you want to learn about Y, ask 'rev-parse', use 'git' itself for Z\".\n>\n> Christian raised the issue of cluttering the \"git --option\" namespace,\n> and I do agree that's a potential issue. \n\nI am not sure if that is an issue at all.  You will need the same\nnumber of options to cover all the necessary \"computables\" somewhere\nanyway.\n\n\"git --show-this-or-that-computable\" is not more or not less\ncluttering compared to \"git var --show-this-or-that-computable\".\n\nIf we were to move to \"git var\", which takes \"variables\" of these\nforms:\n\n\tGIT_AUTHOR_IDENT\n        GIT_COMMITTER_IDENT\n        GIT_EDITOR\n        GIT_PAGER\n\nthen scripts that currently use \"git --exec-path\" need to be\nencouraged to instead use \"git var GIT_EXEC_PATH\".  If we have so\nmany computables that \"cluttering\" may become an issue, then we\nwould need to come up with many new GIT_$COMPUTABLE_NAME fake\nvariables for consistency if we were to go with \"git var\", no?\n\nI understand we are not talking about removing \"git --exec-path\",\nbut the desire is to have one single command the user can go to ask\nabout all the computables.  If \"var\" is to become that single\ncommand, then we need to keep the interface to it uniform and\nconsistent, and telling the users to use \"git var GIT_PAGER\" and\n\"git var --exec-path\" in the same script will not fly well.  Also\nthese GIT_$COMPUTABLE_NAME appear as if they can be influenced by\nsetting environment variables of the same name, which invites\nfurther confusion.  This is especially bad because some of then do\nget affected by environment (i.e. GIT_EDITOR=\"vi\" has effect, but\nGIT_AUTHOR_IDENT=\"Gitster <gitster@pobox.com>\" does not).\n\n> ... My proposal was to drop \"git\n> var\", but I'd also be OK with making \"git var\" the new kitchen sink.  It\n> doesn't accept many options now, so it's fairly wide open for changing\n> without losing backwards compatibility. AFAICT, the \"-l\" option is\n> utterly useless, but other than that, it just takes a variable name. We\n> could introduce dashed options, or just define a sane variable namespace.\n\nIf we admit that \"git var\" was a failed experiment that gained only\nfour fake variables for the past 10 years, it will not be too much\ntrouble and transition pain to turn the existing ones into option\nform, like --author-ident etc., like your original proposal did, I\nwould think.\n\nIf we are going to deprecate \"git var GIT_AUTHOR_IDENT\" form,\ni.e. the form that uses fake variable-looking strings, and uniformly\nuse \"git var --author-ident\", \"git var --exec-path\", etc., then I\nwould think it would work, too.  I still do not know what you gain\nby using \"git var --exec-path\" over \"git --exec-path\", though.\n"},{"id":"253086","messageId":"vpqegsfchi4.fsf@anie.imag.fr","threadId":"38071","inReplyTo":"xmqqlhmntf02.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] introduce git root","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-12-04T20:00:35Z","receivedAt":"2014-12-04T20:00:35Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> Christian raised the issue of cluttering the \"git --option\"\n>> namespace,\n>> and I do agree that's a potential issue. \n>\n> I am not sure if that is an issue at all. You will need the same\n> number of options to cover all the necessary \"computables\" somewhere\n> anyway.\n>\n> \"git --show-this-or-that-computable\" is not more or not less\n> cluttering compared to \"git var --show-this-or-that-computable\".\n\nI disagree.\n\nRight now, a user reading \"man git\" sees --version, --help, -C,\n--exec-path, --html-path, --man-path, ... at a flat list (it's actually\nthe first thing he can read from the man page).\n\nThe point of having commands is to make the features hierarchic. \"git\nrebase\" do many things, but these things are all grouped under the\ncommand \"git rebase\".\n\nIndeed, I would find \"git var\" to be a nice place to group the \"show me\nsuch or such path\". Not sure it's worth the trouble of changing the\nexisting \"git --*-path\", but I think \"git var\" should be the place for\nnew things.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"253091","messageId":"xmqqr3wfrwuu.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"vpqegsfchi4.fsf@anie.imag.fr","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-04T20:19:53Z","receivedAt":"2014-12-04T20:19:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> Jeff King <peff@peff.net> writes:\n>>\n>>> Christian raised the issue of cluttering the \"git --option\"\n>>> namespace,\n>>> and I do agree that's a potential issue. \n>>\n>> I am not sure if that is an issue at all. You will need the same\n>> number of options to cover all the necessary \"computables\" somewhere\n>> anyway.\n>>\n>> \"git --show-this-or-that-computable\" is not more or not less\n>> cluttering compared to \"git var --show-this-or-that-computable\".\n>\n> I disagree.\n>\n> Right now, a user reading \"man git\" sees --version, --help, -C,\n> --exec-path, --html-path, --man-path, ... at a flat list (it's actually\n> the first thing he can read from the man page).\n\nAhh, OK, you are worried about these \"--give-me-computed-values\"\nmixed with other kinds of options.  I didn't consider that part of\nthe equation.\n\nOK, \"git var --exec-path\" (and --friends), that is.\n"},{"id":"253097","messageId":"20141204211232.GC19953@peff.net","threadId":"38071","inReplyTo":"xmqqlhmntf02.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] introduce git root","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-04T21:12:32Z","receivedAt":"2014-12-04T21:12:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 04, 2014 at 11:02:37AM -0800, Junio C Hamano wrote:\n\n> > Christian raised the issue of cluttering the \"git --option\" namespace,\n> > and I do agree that's a potential issue. \n> \n> I am not sure if that is an issue at all.  You will need the same\n> number of options to cover all the necessary \"computables\" somewhere\n> anyway.\n> \n> \"git --show-this-or-that-computable\" is not more or not less\n> cluttering compared to \"git var --show-this-or-that-computable\".\n\nMy issue is only that \"git --foo\" has other options besides computables.\nSo you need to name each option in a way that makes it clear it is\nreporting a computable and not doing something else.\n\nTake \"git --pager\" for instance. That would be a natural choice to\nreplace \"git var GIT_PAGER\". But shouldn't \"--pager\" be the opposite of\nthe existing \"--no-pager\"?\n\nSo instead we probably need some namespace to indicate that it is a\n\"showing\" option. Like \"--show-pager\". And then for consistency, we\nwould probably want to move \"--exec-path\" to \"--show-exec-path\",\ncreating a new \"--show-\" namespace. Or we could call that namespace\n\"git var\". :)\n\n> I understand we are not talking about removing \"git --exec-path\",\n> but the desire is to have one single command the user can go to ask\n> about all the computables.  If \"var\" is to become that single\n> command, then we need to keep the interface to it uniform and\n> consistent, and telling the users to use \"git var GIT_PAGER\" and\n> \"git var --exec-path\" in the same script will not fly well.  Also\n> these GIT_$COMPUTABLE_NAME appear as if they can be influenced by\n> setting environment variables of the same name, which invites\n> further confusion.  This is especially bad because some of then do\n> get affected by environment (i.e. GIT_EDITOR=\"vi\" has effect, but\n> GIT_AUTHOR_IDENT=\"Gitster <gitster@pobox.com>\" does not).\n\nI do not think \"git var --exec-path\" is a good idea, nor GIT_EXEC_PATH\nfor the environment-variable confusion you mentioned. I was thinking of\njust creating a new namespace, like:\n\n  git var exec-path\n  git var author-ident\n\nand deprecating the 4 existing GIT_* variables.\n\n> If we admit that \"git var\" was a failed experiment that gained only\n> four fake variables for the past 10 years, it will not be too much\n> trouble and transition pain to turn the existing ones into option\n> form, like --author-ident etc., like your original proposal did, I\n> would think.\n\nI am also OK with that, if the details turn out to be not too ugly once\nsomebody starts digging in. I was just anticipating some ugliness in\nadvance. :) But I am not planning to work on it in the immediate future,\nso whoever does can make that call.\n\n-Peff\n"},{"id":"253099","messageId":"xmqqfvcvrtls.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"20141204211232.GC19953@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-04T21:30:07Z","receivedAt":"2014-12-04T21:30:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> ... I was thinking of\n> just creating a new namespace, like:\n>\n>   git var exec-path\n>   git var author-ident\n>\n> and deprecating the 4 existing GIT_* variables.\n\nI'm fine with that.  As I wrote in my response to MMoy, I forgot\nabout other kinds of options the \"git\" potty takes, and \"git var\nname-without-needless-double-dashes\" is a perfectly fine way to\nconsolidate the querying of computed values in a single place.\n\nThanks.\n"},{"id":"253149","messageId":"CAP8UFD2P9P9zL=irZ-7uPD6+bEhxaiABowh0O3RT01Ov3VqT6w@mail.gmail.com","threadId":"38071","inReplyTo":"20141204211232.GC19953@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-12-05T02:27:17Z","receivedAt":"2014-12-05T02:27:17Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Jeff King <peff@peff.net> wrote:\n\n> Some of the discussion has involved mixing config options into this\n> kitchen sink, but that does not make any sense to me (and is why I\n> find \"git var -l\" so odd). Config options are fundamentally different, in\n> that they are set and retrieved, not computed (from other config\n> variables, or from hard-coded values). And we already have a nice\n> tool for working with them (well...nice-ish, let's say).\n\nYeah, but \"git config\" cannot say which config option applies in some\ncontext and why.\nFor example, to chose the editor all the following could apply:\n\nGIT_SEQUENCE_EDITOR env variable\nsequence.editor config variable\nGIT_EDITOR env variable\ncore.editor config variable\nVISUAL env variable\nEDITOR env variable\neditor configured at compile time\n\nand the user or our own scripts right now cannot easily know which\neditor should be used when editing the sequence list.\n\nThe best they can do is:\n\n- first check if GIT_SEQUENCE_EDITOR is set, and if yes, use it\n- then check if sequence.editor config variable is set, and if yes, use it\n- then use \"git var GIT_EDITOR\" that will check the other options\n\nI don't think it is very nice.\n\nJeff King <peff@peff.net> also wrote:\n\n> My issue is only that \"git --foo\" has other options besides computables.\n> So you need to name each option in a way that makes it clear it is\n> reporting a computable and not doing something else.\n>\n> Take \"git --pager\" for instance. That would be a natural choice to\n> replace \"git var GIT_PAGER\". But shouldn't \"--pager\" be the opposite of\n> the existing \"--no-pager\"?\n>\n> So instead we probably need some namespace to indicate that it is a\n> \"showing\" option. Like \"--show-pager\". And then for consistency, we\n> would probably want to move \"--exec-path\" to \"--show-exec-path\",\n> creating a new \"--show-\" namespace. Or we could call that namespace\n> \"git var\". :)\n\nI agree with that, but I think it could be better if there was also a\nnotion of context,\n\n> I do not think \"git var --exec-path\" is a good idea, nor GIT_EXEC_PATH\n> for the environment-variable confusion you mentioned. I was thinking of\n> just creating a new namespace, like:\n>\n>   git var exec-path\n>   git var author-ident\n\nI agree that this is nice, but I wonder what we would do for the\nsequence editor and the default editor.\nMaybe:\n\ngit var sequence-editor\ngit var editor\n\nThat would already be nicer than what we have now, but maybe we should\nconsider the following instead:\n\ngit var sequence.editor\ngit var core.editor\n\n(and maybe also some aliases to core.editor, like:\n\ngit var default.editor\ngit var editor)\n\nI think \"sequence.editor\" and \"core.editor\" are better because:\n\n- they use the same syntax as the config variables, so they are easier\nto remember and to discover, and\n- they provide a notion of context.\n\nThe notion of context is interesting because suppose that we later\nintroduce the \"commit.editor\" config variable. If we decide now that\n\"foo.editor\" means just \"core.editor\" if we don't know about any\n\"editor\" variable related to the \"foo\" context, then the scripts that\nmight later be written using \"git var commit.editor\" will not have to\nworry about the fact that previous versions of Git didn't know about\n\"commit.editor\".\n\nPeople could even start using \"git var commit.editor\" now, because it\nwould work even if \"commit.editor\" is unused by git commit.\n\nOf course when the user asks for \"git var foo.editor\" and we don't\nknow about any \"editor\" variable related to the \"foo\" context, we\nfirst should check if \"foo.editor\" exists in the config file and we\nshould use that if it exists, before we default to \"git var\ncore.editor\".\n\nBest,\nChristian.\n"},{"id":"253156","messageId":"20141205092752.GC32112@peff.net","threadId":"38071","inReplyTo":"CAP8UFD2P9P9zL=irZ-7uPD6+bEhxaiABowh0O3RT01Ov3VqT6w@mail.gmail.com","subject":"Re: [PATCH] introduce git root","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-05T09:27:52Z","receivedAt":"2014-12-05T09:27:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:\n\n> For example, to chose the editor all the following could apply:\n> \n> GIT_SEQUENCE_EDITOR env variable\n> sequence.editor config variable\n> GIT_EDITOR env variable\n> core.editor config variable\n> VISUAL env variable\n> EDITOR env variable\n> editor configured at compile time\n> \n> and the user or our own scripts right now cannot easily know which\n> editor should be used when editing the sequence list.\n\nI think we're violently agreeing.\n\nTaking all of those inputs and computing the final value for a\ngit-sequence editor is exactly what \"git var\" should be doing. IMHO it\nis a bug that when GIT_SEQUENCE_EDITOR was introduced, there was not a\nmatching update to compute it from \"git var\" (I didn't even know\nsequence.editor existed until now!).\n\nI am not opposed to that at all; that's the point of \"git var\", and the\n\"computables\" we are talking about. I am only opposed to mixing the\nnamespace for computables with config. I.e., there is no point in asking\n\"git var\" for the core.editor config. It is not a computable value, and\nwe already have a way of accessing it (git-config, which can also\n_write_ the value, something that git-var will never be able to do for\ncomputable values).\n\n> > I do not think \"git var --exec-path\" is a good idea, nor GIT_EXEC_PATH\n> > for the environment-variable confusion you mentioned. I was thinking of\n> > just creating a new namespace, like:\n> >\n> >   git var exec-path\n> >   git var author-ident\n> \n> I agree that this is nice, but I wonder what we would do for the\n> sequence editor and the default editor.\n> Maybe:\n> \n> git var sequence-editor\n> git var editor\n\nAgain, I think we're mostly agreeing. Context and hierarchy and falling\nback are good things. Whatever we call the variables, \"editor\" and\n\"sequence-editor\" and \"foo-editor\" should have a predictable and\nconsistent form. I like the idea of \"foo-editor\" automatically falling\nback to \"editor\" even if we don't know what \"foo\" is.\n\nBut the one place I do not agree is:\n\n> I think \"sequence.editor\" and \"core.editor\" are better because:\n> \n> - they use the same syntax as the config variables, so they are easier\n> to remember and to discover, and\n\nI really don't like using \"core.editor\" here, because it has the same\nname as a config variable, but it is _not_ the config variable. It\nhappens to use the config variable as one of the inputs to its\ncomputation, but in many cases:\n\n  git config core.editor\n\nand\n\n  git var core.editor\n\nwill produce different values. They are entirely different namespaces.\nUsing the same syntax and name seems unnecessarily confusing to me. Even\nstill using dotted hierarchies, but giving them different names (e.g.,\n\"editor\", \"editor.sequence\", \"editor.foo\") would make it more obvious\nthat they are not the same thing.\n\n-Peff\n"},{"id":"253261","messageId":"CAP8UFD3mXJEHOfSoW6-B8uAR0gv2ZKWUhAs1SpNr17wVsRpM6g@mail.gmail.com","threadId":"38071","inReplyTo":"20141205092752.GC32112@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-12-07T05:23:54Z","receivedAt":"2014-12-07T05:23:54Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Dec 5, 2014 at 10:27 AM, Jeff King <peff@peff.net> wrote:\n> On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:\n>\n>> > I do not think \"git var --exec-path\" is a good idea, nor GIT_EXEC_PATH\n>> > for the environment-variable confusion you mentioned. I was thinking of\n>> > just creating a new namespace, like:\n>> >\n>> >   git var exec-path\n>> >   git var author-ident\n>>\n>> I agree that this is nice, but I wonder what we would do for the\n>> sequence editor and the default editor.\n>> Maybe:\n>>\n>> git var sequence-editor\n>> git var editor\n>\n> Again, I think we're mostly agreeing. Context and hierarchy and falling\n> back are good things. Whatever we call the variables, \"editor\" and\n> \"sequence-editor\" and \"foo-editor\" should have a predictable and\n> consistent form. I like the idea of \"foo-editor\" automatically falling\n> back to \"editor\" even if we don't know what \"foo\" is.\n\nYeah but that means that we have to use something other than \"-\" to\nseparate the context from the name, because we already have names like\nexec-path, html-path and man-path.\n\n> But the one place I do not agree is:\n>\n>> I think \"sequence.editor\" and \"core.editor\" are better because:\n>>\n>> - they use the same syntax as the config variables, so they are easier\n>> to remember and to discover, and\n>\n> I really don't like using \"core.editor\" here, because it has the same\n> name as a config variable, but it is _not_ the config variable. It\n> happens to use the config variable as one of the inputs to its\n> computation, but in many cases:\n>\n>   git config core.editor\n>\n> and\n>\n>   git var core.editor\n>\n> will produce different values.\n\nYeah, but I don't think it is a problem. They are different commands,\nso it can be expected that they do different things.\n\nFor example, if you use \"git log origin/master\" you get a different\nouput than if you use \"git show origin/master\", though you still use\nthe same \"origin/master\" notation.\n\nWhen you use \"git show\" you consider only the commit pointed to by\norigin/master and when you use \"git log\" you consider the same commit\nbut also all its ancestors.\n\nIn the same way, when you use \"git config core.editor\" you consider\nonly the value of the core.editor logical variable in the config\nfiles, while when you would use \"git var core.editor\" you would\nconsider the value of the core.editor logical variable in both the\nconfig files and the environment variables.\n\n> They are entirely different namespaces.\n> Using the same syntax and name seems unnecessarily confusing to me. Even\n> still using dotted hierarchies, but giving them different names (e.g.,\n> \"editor\", \"editor.sequence\", \"editor.foo\") would make it more obvious\n> that they are not the same thing.\n\nUsing yet another namespace or syntax when we could reuse an existing\none is what would seem unnecessarily confusing to me.\nThe value of the \"editor\" logical variable in the \"sequence\" context\nis related to the \"sequence.editor\" logical value in the config file,\nbecause the later can directly influence the former. So there is a\nreason to use the same notation.\n\nBest,\nChristian.\n"},{"id":"253423","messageId":"xmqqoarcn0wm.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"20141205092752.GC32112@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-09T18:17:13Z","receivedAt":"2014-12-09T18:17:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> But the one place I do not agree is:\n>\n>> I think \"sequence.editor\" and \"core.editor\" are better because:\n>> \n>> - they use the same syntax as the config variables, so they are easier\n>> to remember and to discover, and\n>\n> I really don't like using \"core.editor\" here, because it has the same\n> name as a config variable, but it is _not_ the config variable. It\n> happens to use the config variable as one of the inputs to its\n> computation, but in many cases:\n>\n>   git config core.editor\n>\n> and\n>\n>   git var core.editor\n>\n> will produce different values. They are entirely different namespaces.\n> Using the same syntax and name seems unnecessarily confusing to me.\n\nI think this is a valid concern.\n\nIt is a tangent, the current definition of \"git_editor\" helper reads\nlike this:\n\n        git_editor() {\n                if test -z \"${GIT_EDITOR:+set}\"\n                then\n                        GIT_EDITOR=\"$(git var GIT_EDITOR)\" || return $?\n                fi\n\n                eval \"$GIT_EDITOR\" '\"$@\"'\n        }\n\nIf \"git var editor\" were to compute a reasonable value from the\nvarious user settings, and because GIT_EDITOR is among the sources\nof user settings, I wonder if the surrounding \"if test -z then...fi\"\nshould be there.\n\nThe pager side seems to do (halfway) \"the right thing\":\n\n        git_pager() {\n                if test -t 1\n                then\n                        GIT_PAGER=$(git var GIT_PAGER)\n                else\n                        GIT_PAGER=cat\n                fi\n                : ${LESS=-FRX}\n                : ${LV=-c}\n                export LESS LV\n\n                eval \"$GIT_PAGER\" '\"$@\"'\n        }\n\nThe initial \"test -t 1\" is \"we do not page to non-terminal\", but we\nask \"git var\" to take care of PAGER/GIT_PAGER fallback/precedence.\n\nIt is tempting to argue that \"we do not page to non-terminal\" should\nalso be part of \"various user settings\" for \"git var\" to take into\naccount and fold this \"if test -t 1...then...else...fi\" also into\n\"git var\", but because a typical command line \"git var\" will be used\non would look like this:\n\n\tGIT_PAGER=$(git var pager)\n        eval \"$GIT_PAGER\" ...\n\nwith the standard output stream of \"git var\" not connected to\nterminal, that would not fly very well, and I am not sure what\nshould be done about it.\n\nThis is another tangent that comes back to the original \"how to name\nthem?\" question, but I wonder if a convention like this would work.\n\n * When asking for a feature (e.g. \"what editor to use\"), if there\n   is a git-specific environment variable that can be set to\n   override all other settings (e.g. \"$GIT_EDITOR\" trumps \"$EDITOR\"\n   environment or \"core.editor\" configuration), \"git var\" can be\n   queried with the name of that \"strong\" environment variable.\n\n * All other features without such a strong environment variables\n   should not be spelled as if there is such an environment variable\n   the user can set in order to avoid confusion.\n\nHere are some consequences that come to my mind, if we adopt such an\napproach:\n\n * We would keep GIT_EDITOR and GIT_PAGER (e.g. \"git var\n   GIT_EDITOR\");\n\n * GIT_SEQUENCE_EDITOR is an example of an overriding environment\n   variable, and as such, \"what editor to use when munging the\n   rebase insn sheet?\", would be \"git var GIT_SEQUENCE_EDITOR\".\n\n * We would deprecate GIT_AUTHOR_IDENT and GIT_COMMITTER_IDENT\n   because setting such an environment variable would not do\n   anything.  Add \"git var author-ident\" that is clear that it does\n   not name an environment variable as its replacement.\n\n * It is OK to add support for new queries, e.g. GIT_AUTHOR_DATE,\n   for existing environment variables that we already take into\n   account but that the current \"git var\" does not support.\n\nArguably, we could go the other way around.  Instead of adding \"git\nvar author-ident\", we actually allow GIT_AUTHOR_IDENT environment\nvariable to be set and used instead of GIT_AUTHOR_{NAME,EMAIL,DATE}.\nIf that approach is practical, then we could stick to the syntax\nthat looks like an environment variable name.  A script could then\ninstead of doing:\n\n\tGIT_AUTHOR_IDENT=$(git var GIT_AUTHOR_IDENT)\n        ... parse it into NAME,EMAIL,DATE and ...\n        export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE\n\n        ... complicated set of operations to prepare ...\n\n        git commit-tree ...\n\ndo this instead:\n\n\tGIT_AUTHOR_IDENT=$(git var GIT_AUTHOR_IDENT)\n        export GIT_AUTHOR_IDENT\n\n        ... complicated set of operations to prepare ...\n\n        git commit-tree ...\n"},{"id":"253485","messageId":"CAP8UFD3U4BjAoebuL3dPGCqWM4T5y8GKUzhwgW=cx700hJd3zg@mail.gmail.com","threadId":"38071","inReplyTo":"xmqqoarcn0wm.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] introduce git root","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-12-10T09:16:38Z","receivedAt":"2014-12-10T09:16:38Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Dec 9, 2014 at 7:17 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> But the one place I do not agree is:\n>>\n>>> I think \"sequence.editor\" and \"core.editor\" are better because:\n>>>\n>>> - they use the same syntax as the config variables, so they are easier\n>>> to remember and to discover, and\n>>\n>> I really don't like using \"core.editor\" here, because it has the same\n>> name as a config variable, but it is _not_ the config variable. It\n>> happens to use the config variable as one of the inputs to its\n>> computation, but in many cases:\n>>\n>>   git config core.editor\n>>\n>> and\n>>\n>>   git var core.editor\n>>\n>> will produce different values. They are entirely different namespaces.\n>> Using the same syntax and name seems unnecessarily confusing to me.\n>\n> I think this is a valid concern.\n>\n> It is a tangent, the current definition of \"git_editor\" helper reads\n> like this:\n>\n>         git_editor() {\n>                 if test -z \"${GIT_EDITOR:+set}\"\n>                 then\n>                         GIT_EDITOR=\"$(git var GIT_EDITOR)\" || return $?\n>                 fi\n>\n>                 eval \"$GIT_EDITOR\" '\"$@\"'\n>         }\n>\n> If \"git var editor\" were to compute a reasonable value from the\n> various user settings, and because GIT_EDITOR is among the sources\n> of user settings, I wonder if the surrounding \"if test -z then...fi\"\n> should be there.\n>\n> The pager side seems to do (halfway) \"the right thing\":\n>\n>         git_pager() {\n>                 if test -t 1\n>                 then\n>                         GIT_PAGER=$(git var GIT_PAGER)\n>                 else\n>                         GIT_PAGER=cat\n>                 fi\n>                 : ${LESS=-FRX}\n>                 : ${LV=-c}\n>                 export LESS LV\n>\n>                 eval \"$GIT_PAGER\" '\"$@\"'\n>         }\n>\n> The initial \"test -t 1\" is \"we do not page to non-terminal\", but we\n> ask \"git var\" to take care of PAGER/GIT_PAGER fallback/precedence.\n>\n> It is tempting to argue that \"we do not page to non-terminal\" should\n> also be part of \"various user settings\" for \"git var\" to take into\n> account and fold this \"if test -t 1...then...else...fi\" also into\n> \"git var\", but because a typical command line \"git var\" will be used\n> on would look like this:\n>\n>         GIT_PAGER=$(git var pager)\n>         eval \"$GIT_PAGER\" ...\n>\n> with the standard output stream of \"git var\" not connected to\n> terminal, that would not fly very well, and I am not sure what\n> should be done about it.\n>\n> This is another tangent that comes back to the original \"how to name\n> them?\" question, but I wonder if a convention like this would work.\n>\n>  * When asking for a feature (e.g. \"what editor to use\"), if there\n>    is a git-specific environment variable that can be set to\n>    override all other settings (e.g. \"$GIT_EDITOR\" trumps \"$EDITOR\"\n>    environment or \"core.editor\" configuration), \"git var\" can be\n>    queried with the name of that \"strong\" environment variable.\n>\n>  * All other features without such a strong environment variables\n>    should not be spelled as if there is such an environment variable\n>    the user can set in order to avoid confusion.\n\nDoes that mean that we would also have the following:\n\n- git var GIT_DIR\n- git var GIT_EXEC_PATH\n- git var GIT_HTML_PATH\n- git var GIT_WORK_TREE\n- git var GIT_PREFIX\n...\n\nbut not:\n\n- git var GIT_SHARED_INDEX_PATH\n- git var GIT_TOP_LEVEL\n- git var GIT_CDUP\n\n?\n\nFor the above 3 variables we would have:\n\n- git var shared-index-path\n- git var top-level\n- git var cdup\n\nAnd then what if we add the GIT_SHARED_INDEX_PATH env variable for example?\nWould we need to deprecate \"git var shared-index-path\"?\n\nWe also would have:\n\n- git var GIT_EDITOR\n\nbut:\n\n- git var web-browser (or \"git var web.browser\" like the config option?)\n\nAnd when we add a GIT_WEB_BROWSER or GIT_BROWSER env variable, we\ndeprecate \"git var web-browser\" (or \"git var web.browser\"?)\n\nI doesn't look like user and future friendly to me, but maybe I\nmisunderstood something.\n\nThanks,\nChristian.\n"},{"id":"253532","messageId":"20141210201057.GC23273@peff.net","threadId":"38071","inReplyTo":"xmqqoarcn0wm.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] introduce git root","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-12-10T20:10:57Z","receivedAt":"2014-12-10T20:10:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:\n\n> It is a tangent, the current definition of \"git_editor\" helper reads\n> like this:\n> \n>         git_editor() {\n>                 if test -z \"${GIT_EDITOR:+set}\"\n>                 then\n>                         GIT_EDITOR=\"$(git var GIT_EDITOR)\" || return $?\n>                 fi\n> \n>                 eval \"$GIT_EDITOR\" '\"$@\"'\n>         }\n> \n> If \"git var editor\" were to compute a reasonable value from the\n> various user settings, and because GIT_EDITOR is among the sources\n> of user settings, I wonder if the surrounding \"if test -z then...fi\"\n> should be there.\n\nI think it should not be. The point of \"git var\" is to say \"compute for\nme what the internal C code would compute\". I think it happens to be a\nnoop in this case, because the C code will give GIT_EDITOR preference\nover anything else. But it seems like a layering violation; the shell\nscripts should not have to know or care about the existence $GIT_EDITOR.\n\n> The pager side seems to do (halfway) \"the right thing\":\n> \n>         git_pager() {\n>                 if test -t 1\n>                 then\n>                         GIT_PAGER=$(git var GIT_PAGER)\n>                 else\n>                         GIT_PAGER=cat\n>                 fi\n>                 : ${LESS=-FRX}\n>                 : ${LV=-c}\n>                 export LESS LV\n> \n>                 eval \"$GIT_PAGER\" '\"$@\"'\n>         }\n> \n> The initial \"test -t 1\" is \"we do not page to non-terminal\", but we\n> ask \"git var\" to take care of PAGER/GIT_PAGER fallback/precedence.\n> \n> It is tempting to argue that \"we do not page to non-terminal\" should\n> also be part of \"various user settings\" for \"git var\" to take into\n> account and fold this \"if test -t 1...then...else...fi\" also into\n> \"git var\", but because a typical command line \"git var\" will be used\n> on would look like this:\n> \n> \tGIT_PAGER=$(git var pager)\n>         eval \"$GIT_PAGER\" ...\n> \n> with the standard output stream of \"git var\" not connected to\n> terminal, that would not fly very well, and I am not sure what\n> should be done about it.\n\nRight, I think in an ideal world the \"is it a terminal\" context is\nhandled by \"git var\", but the reality of shell scripts makes it hard. We\nface the same problem with \"git config --get-colorbool\". There we cheat\na little and use the exit code to signal the result. That works for a\nbool, but not for a string. :)\n\nI think you'd have to do something a little gross like:\n\n  pager=$(git var GIT_PAGER >&3) 3>&1\n\nExcept that doesn't work; the shell does not take redirections for a\nstraight variable assignment. Something like:\n\n  # git var uses fd 3 by convention for stdout-tty tests\n  exec 3>&1\n\nat the top of git-sh-setup, and then:\n\n  pager=$(git var GIT_PAGER >&3)\n\nin the scripts themselves. That works, but is a bit ugly.\n\n> This is another tangent that comes back to the original \"how to name\n> them?\" question, but I wonder if a convention like this would work.\n> \n>  * When asking for a feature (e.g. \"what editor to use\"), if there\n>    is a git-specific environment variable that can be set to\n>    override all other settings (e.g. \"$GIT_EDITOR\" trumps \"$EDITOR\"\n>    environment or \"core.editor\" configuration), \"git var\" can be\n>    queried with the name of that \"strong\" environment variable.\n\nI'd prefer to create a new namespace. When you set $GIT_EDITOR as a\n\"trump\" variable, then that is leaking information about the computation\nfrom \"git var\" out to the caller. What happens if the computation\nchanges so that $GIT_EDITOR is no longer the last word?\n\n>  * All other features without such a strong environment variables\n>    should not be spelled as if there is such an environment variable\n>    the user can set in order to avoid confusion.\n\nSo now you have two classes of variables. Some that look like\nenvironment variables, and some that do not. What does it buy you for\nthe ones that do look like environment variables? I feel like either way\nyou will still use them as:\n\n  editor=$(git var editor)\n  eval \"$editor\" \"$@\"\n\nDoes it matter whether you call it $editor or $GIT_EDITOR?\n\n-Peff\n"},{"id":"253536","messageId":"xmqq7fxzgql2.fsf@gitster.dls.corp.google.com","threadId":"38071","inReplyTo":"20141210201057.GC23273@peff.net","subject":"Re: [PATCH] introduce git root","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-12-10T21:08:57Z","receivedAt":"2014-12-10T21:08:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:\n>\n>> This is another tangent that comes back to the original \"how to name\n>> them?\" question, but I wonder if a convention like this would work.\n>> \n>>  * When asking for a feature (e.g. \"what editor to use\"), if there\n>>    is a git-specific environment variable that can be set to\n>>    override all other settings (e.g. \"$GIT_EDITOR\" trumps \"$EDITOR\"\n>>    environment or \"core.editor\" configuration), \"git var\" can be\n>>    queried with the name of that \"strong\" environment variable.\n>\n> I'd prefer to create a new namespace. When you set $GIT_EDITOR as a\n> \"trump\" variable, then that is leaking information about the computation\n> from \"git var\" out to the caller. What happens if the computation\n> changes so that $GIT_EDITOR is no longer the last word?\n\nHaving two classes of variables, ones that have their corresponding\n\"trump\" environment variables and others (and making the users aware\nof the \"trump\" variables) is a way to teach users that they could\nuse them when they want to tweak the specific aspect of Git.  It of\ncourse casts what variable trumps all others in stone, which is a\nprerequisite if we want to have something stable and teachable to\nthe users.  Casting in stone will hinder future improvements, so the\nargument cuts both ways.\n\nHaving said that, this was not even a suggestion or a proposal (in\nthe sense that I would be happier if people agreed on this design\nrather than other design).  I'd be happy as long as people agreed on\nanything sensible.\n\n> So now you have two classes of variables. Some that look like\n> environment variables, and some that do not. What does it buy you for\n> the ones that do look like environment variables?\n\nTeachability.  I personally do not care too much about it, though\n;-)\n\nI would have used a separate namespace for the ones without \"trump\"\nvariables, and would have given aliases in that namespace even for\nthe ones with \"trump\" variables, so it does not make much difference\nto my mind---we will have the third namespace anyway whether we went\nthe \"trumps can be queried via the environment variable name\"\noption or not.\n\nSo it seems that we agree that a separate namespace that is clearly\ndistinct from environment or config would be the way to go?\n"}]}