{"thread":{"id":"56039","subject":"[PATCH 0/5] Default aliases","startedAt":"2021-07-02T10:05:12Z","lastAt":"2021-07-10T15:31:00Z","messageCount":41,"participants":["Felipe Contreras","Andreas Schwab","martin","Ævar Arnfjörð Bjarmason","Randall S. Becker","Junio C Hamano","Jeff King","Philip Oakley"],"isPatch":true,"patchVersion":1,"patchTotal":5},"messages":[{"id":"429014","messageId":"20210702100506.1422429-1-felipe.contreras@gmail.com","threadId":"56039","inReplyTo":null,"subject":"[PATCH 0/5] Default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:05:01Z","receivedAt":"2021-07-02T10:05:12Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Virtually all VCS in history have default aliases, except git. Let's\nfix that.\n\nTo make the aliases uncontroversial all of them have to follow certain\nrules:\n\n 1) Each default alias should have two characters\n 2) Each default alias should map to a command without arguments\n 3) Each default alias be widely used in the wild\n\nThe list of default aliases on this series have been discussed before,\nand even Junio stated \"I think it might be OK to implement them\" [1].\nSince git is virtually unusable without aliases, it's an imperative to\nmake it useful by default.\n\nAdditionally, users should be able to override the default aliases\nwithout any issue.\n\n[1] https://lore.kernel.org/git/xmqqtx9m8obr.fsf@gitster.dls.corp.google.com/\n\nFelipe Contreras (5):\n test: add missing whitespaces\n config: trivial style fix\n config: trivial struct initialization cleanup\n config: initialize origin_type correctly\n config: add default aliases\n\n Documentation/git-branch.txt | 4 +++\n Documentation/git-cherry-pick.txt | 4 +++\n Documentation/git-commit.txt | 4 +++\n Documentation/git-mergetool.txt | 4 +++\n Documentation/git-rebase.txt | 4 +++\n Documentation/git-status.txt | 4 +++\n config.c | 44 +++++++++++++++++++++++++------\n config.h | 3 ++-\n t/t1300-config.sh | 1 +\n t/test-lib.sh | 3 +++\n 10 files changed, 66 insertions(+), 9 deletions(-)\n\n-- \n2.32.0.94.g4574ca548c\n\n"},{"id":"429015","messageId":"20210702100506.1422429-2-felipe.contreras@gmail.com","threadId":"56039","inReplyTo":"20210702100506.1422429-1-felipe.contreras@gmail.com","subject":"[PATCH 1/5] test: add missing whitespaces","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:05:02Z","receivedAt":"2021-07-02T10:05:13Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n t/t1300-config.sh | 1 +\n t/test-lib.sh | 1 +\n 2 files changed, 2 insertions(+)\n\ndiff --git a/t/t1300-config.sh b/t/t1300-config.sh\nindex 9ff46f3b04..453222b32f 100755\n--- a/t/t1300-config.sh\n+++ b/t/t1300-config.sh\n@@ -335,6 +335,7 @@ test_expect_success 'working --list' '\n \tgit config --list > output &&\n \ttest_cmp expect output\n '\n+\n test_expect_success '--list without repo produces empty output' '\n \tgit --git-dir=nonexistent config --list >output &&\n \ttest_must_be_empty output\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 54938c6427..49b80a4eb5 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -430,6 +430,7 @@ unset VISUAL EMAIL LANGUAGE COLUMNS $(\"$PERL_PATH\" -e '\n \tmy @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);\n \tprint join(\"\\n\", @vars);\n ')\n+\n unset XDG_CACHE_HOME\n unset XDG_CONFIG_HOME\n unset GITPERLLIB\n-- \n2.32.0.94.g4574ca548c\n\n"},{"id":"429016","messageId":"20210702100506.1422429-3-felipe.contreras@gmail.com","threadId":"56039","inReplyTo":"20210702100506.1422429-1-felipe.contreras@gmail.com","subject":"[PATCH 2/5] config: trivial style fix","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:05:03Z","receivedAt":"2021-07-02T10:05:16Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n config.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/config.c b/config.c\nindex f9c400ad30..dc896c434e 100644\n--- a/config.c\n+++ b/config.c\n@@ -3482,7 +3482,7 @@ const char *current_config_origin_type(void)\n \tint type;\n \tif (current_config_kvi)\n \t\ttype = current_config_kvi->origin_type;\n-\telse if(cf)\n+\telse if (cf)\n \t\ttype = cf->origin_type;\n \telse\n \t\tBUG(\"current_config_origin_type called outside config callback\");\n-- \n2.32.0.94.g4574ca548c\n\n"},{"id":"429017","messageId":"20210702100506.1422429-4-felipe.contreras@gmail.com","threadId":"56039","inReplyTo":"20210702100506.1422429-1-felipe.contreras@gmail.com","subject":"[PATCH 3/5] config: trivial struct initialization cleanup","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:05:04Z","receivedAt":"2021-07-02T10:05:18Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Signed-off-by: Felipe Contreras \n---\n config.c | 10 +++++-----\n 1 file changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/config.c b/config.c\nindex dc896c434e..9172c96c54 100644\n--- a/config.c\n+++ b/config.c\n@@ -2265,11 +2265,11 @@ int git_configset_get_pathname(struct config_set *cs, const char *key, const cha\n /* Functions use to read configuration from a repository */\n static void repo_read_config(struct repository *repo)\n {\n-\tstruct config_options opts = { 0 };\n-\n-\topts.respect_includes = 1;\n-\topts.commondir = repo->commondir;\n-\topts.git_dir = repo->gitdir;\n+\tstruct config_options opts = {\n+\t\t.respect_includes = 1,\n+\t\t.commondir = repo->commondir,\n+\t\t.git_dir = repo->gitdir,\n+\t};\n \n \tif (!repo->config)\n \t\tCALLOC_ARRAY(repo->config, 1);\n-- \n2.32.0.94.g4574ca548c\n\n"},{"id":"429018","messageId":"20210702100506.1422429-5-felipe.contreras@gmail.com","threadId":"56039","inReplyTo":"20210702100506.1422429-1-felipe.contreras@gmail.com","subject":"[PATCH 4/5] config: initialize origin_type correctly","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:05:05Z","receivedAt":"2021-07-02T10:05:20Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"cf->origin_type either is CONFIG_ORIGIN_CMDLINE, or it's something else.\n\nDon't override that.\n\nSigned-off-by: Felipe Contreras \n---\n config.c | 3 +--\n 1 file changed, 1 insertion(+), 2 deletions(-)\n\ndiff --git a/config.c b/config.c\nindex 9172c96c54..666fb2c689 100644\n--- a/config.c\n+++ b/config.c\n@@ -2087,13 +2087,12 @@ static int configset_add_value(struct config_set *cs, const char *key, const cha\n \tif (cf->name) {\n \t\tkv_info->filename = strintern(cf->name);\n \t\tkv_info->linenr = cf->linenr;\n-\t\tkv_info->origin_type = cf->origin_type;\n \t} else {\n \t\t/* for values read from `git_config_from_parameters()` */\n \t\tkv_info->filename = NULL;\n \t\tkv_info->linenr = -1;\n-\t\tkv_info->origin_type = CONFIG_ORIGIN_CMDLINE;\n \t}\n+\tkv_info->origin_type = cf->origin_type;\n \tkv_info->scope = current_parsing_scope;\n \tsi->util = kv_info;\n \n-- \n2.32.0.94.g4574ca548c\n\n"},{"id":"429019","messageId":"20210702100506.1422429-6-felipe.contreras@gmail.com","threadId":"56039","inReplyTo":"20210702100506.1422429-1-felipe.contreras@gmail.com","subject":"[PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:05:06Z","receivedAt":"2021-07-02T10:05:22Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"These are all the aliases everyone agrees are essential.\n\nVirtually all VCS in the world have aliases, except git, so let's change\nthat.\n\nSigned-off-by: Felipe Contreras \n---\n Documentation/git-branch.txt | 4 ++++\n Documentation/git-cherry-pick.txt | 4 ++++\n Documentation/git-commit.txt | 4 ++++\n Documentation/git-mergetool.txt | 4 ++++\n Documentation/git-rebase.txt | 4 ++++\n Documentation/git-status.txt | 4 ++++\n config.c | 29 +++++++++++++++++++++++++++++\n config.h | 3 ++-\n t/test-lib.sh | 2 ++\n 9 files changed, 57 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 94dc9a54f2..fbf5ebd27a 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -24,6 +24,10 @@ SYNOPSIS\n 'git branch' (-d | -D) [-r] ...\n 'git branch' --edit-description []\n \n+ALIAS\n+~~~~~\n+'git br'\n+\n DESCRIPTION\n -----------\n \ndiff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt\nindex 5d750314b2..b43b1a3a30 100644\n--- a/Documentation/git-cherry-pick.txt\n+++ b/Documentation/git-cherry-pick.txt\n@@ -12,6 +12,10 @@ SYNOPSIS\n \t\t [-S[]] ...\n 'git cherry-pick' (--continue | --skip | --abort | --quit)\n \n+ALIAS\n+~~~~~\n+'git pi'\n+\n DESCRIPTION\n -----------\n \ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 340c5fbb48..32b1fdba45 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -17,6 +17,10 @@ SYNOPSIS\n \t [(--trailer [(=|:)])...] [-S[]]\n \t [--] [...]\n \n+ALIAS\n+~~~~~\n+'git co'\n+\n DESCRIPTION\n -----------\n Create a new commit containing the current contents of the index and\ndiff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt\nindex e587c7763a..59708a1f3e 100644\n--- a/Documentation/git-mergetool.txt\n+++ b/Documentation/git-mergetool.txt\n@@ -10,6 +10,10 @@ SYNOPSIS\n [verse]\n 'git mergetool' [--tool=] [-y | --[no-]prompt] [...]\n \n+ALIAS\n+~~~~~\n+'git mt'\n+\n DESCRIPTION\n -----------\n \ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 55af6fd24e..21f5ae9d0e 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -14,6 +14,10 @@ SYNOPSIS\n \t--root []\n 'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)\n \n+ALIAS\n+~~~~~\n+'git rb'\n+\n DESCRIPTION\n -----------\n If is specified, 'git rebase' will perform an automatic\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex 83f38e3198..fcc89fa8d4 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -11,6 +11,10 @@ SYNOPSIS\n [verse]\n 'git status' [...] [--] [...]\n \n+ALIAS\n+~~~~~\n+'git st'\n+\n DESCRIPTION\n -----------\n Displays paths that have differences between the index file and the\ndiff --git a/config.c b/config.c\nindex 666fb2c689..c42f41599c 100644\n--- a/config.c\n+++ b/config.c\n@@ -501,6 +501,30 @@ int git_config_key_is_valid(const char *key)\n \treturn !git_config_parse_key_1(key, NULL, NULL, 1);\n }\n \n+static int git_config_default(config_fn_t fn, void *data)\n+{\n+\tint ret = 0;\n+\tstruct config_source source;\n+\n+\tif (getenv(\"GIT_NO_DEFAULT_ALIASES\"))\n+\t\treturn 0;\n+\n+\tmemset(&source, 0, sizeof(source));\n+\tsource.prev = cf;\n+\tsource.origin_type = CONFIG_ORIGIN_DEFAULT;\n+\tcf = &source;\n+\n+\tret += fn(\"alias.co\", \"commit\", data);\n+\tret += fn(\"alias.rb\", \"rebase\", data);\n+\tret += fn(\"alias.st\", \"status\", data);\n+\tret += fn(\"alias.br\", \"branch\", data);\n+\tret += fn(\"alias.pi\", \"cherry-pick\", data);\n+\tret += fn(\"alias.mt\", \"mergetool\", data);\n+\n+\tcf = source.prev;\n+\treturn ret;\n+}\n+\n static int config_parse_pair(const char *key, const char *value,\n \t\t\t config_fn_t fn, void *data)\n {\n@@ -1897,6 +1921,9 @@ static int do_git_config_sequence(const struct config_options *opts,\n \t\trepo_config = NULL;\n \n \tcurrent_parsing_scope = CONFIG_SCOPE_SYSTEM;\n+\n+\tgit_config_default(fn, data);\n+\n \tif (git_config_system() && system_config &&\n \t !access_or_die(system_config, R_OK,\n \t\t\t opts->system_gently ? ACCESS_EACCES_OK : 0))\n@@ -3497,6 +3524,8 @@ const char *current_config_origin_type(void)\n \t\treturn \"submodule-blob\";\n \tcase CONFIG_ORIGIN_CMDLINE:\n \t\treturn \"command line\";\n+\tcase CONFIG_ORIGIN_DEFAULT:\n+\t\treturn \"default\";\n \tdefault:\n \t\tBUG(\"unknown config origin type\");\n \t}\ndiff --git a/config.h b/config.h\nindex 9038538ffd..bc3ecca313 100644\n--- a/config.h\n+++ b/config.h\n@@ -58,7 +58,8 @@ enum config_origin_type {\n \tCONFIG_ORIGIN_FILE,\n \tCONFIG_ORIGIN_STDIN,\n \tCONFIG_ORIGIN_SUBMODULE_BLOB,\n-\tCONFIG_ORIGIN_CMDLINE\n+\tCONFIG_ORIGIN_CMDLINE,\n+\tCONFIG_ORIGIN_DEFAULT\n };\n \n enum config_event_t {\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 49b80a4eb5..a15965e2f4 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -456,6 +456,8 @@ GIT_DEFAULT_HASH=\"${GIT_TEST_DEFAULT_HASH:-sha1}\"\n export GIT_DEFAULT_HASH\n GIT_TEST_MERGE_ALGORITHM=\"${GIT_TEST_MERGE_ALGORITHM:-ort}\"\n export GIT_TEST_MERGE_ALGORITHM\n+GIT_NO_DEFAULT_ALIASES=1\n+export GIT_NO_DEFAULT_ALIASES\n \n # Tests using GIT_TRACE typically don't want : output\n GIT_TRACE_BARE=1\n-- \n2.32.0.94.g4574ca548c\n\n"},{"id":"429020","messageId":"871r8hauvi.fsf@igel.home","threadId":"56039","inReplyTo":"20210702100506.1422429-6-felipe.contreras@gmail.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2021-07-02T10:10:57Z","receivedAt":"2021-07-02T10:11:03Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Jul 02 2021, Felipe Contreras wrote:\n\n> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n> index 340c5fbb48..32b1fdba45 100644\n> --- a/Documentation/git-commit.txt\n> +++ b/Documentation/git-commit.txt\n> @@ -17,6 +17,10 @@ SYNOPSIS\n> \t [(--trailer [(=|:)])...] [-S[]]\n> \t [--] [...]\n> \n> +ALIAS\n> +~~~~~\n> +'git co'\n\nThat's `checkout' in hg, bzr, svn and cvs.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"429022","messageId":"60dee7d4e27bf_2964b20817@natae.notmuch","threadId":"56039","inReplyTo":"871r8hauvi.fsf@igel.home","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:17:56Z","receivedAt":"2021-07-02T10:18:02Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andreas Schwab wrote:\n> On Jul 02 2021, Felipe Contreras wrote:\n> \n> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n> > index 340c5fbb48..32b1fdba45 100644\n> > --- a/Documentation/git-commit.txt\n> > +++ b/Documentation/git-commit.txt\n> > @@ -17,6 +17,10 @@ SYNOPSIS\n> > \t [(--trailer [(=|:)])...] [-S[]]\n> > \t [--] [...]\n> > \n> > +ALIAS\n> > +~~~~~\n> > +'git co'\n> \n> That's `checkout' in hg, bzr, svn and cvs.\n\nI know, and commit is ci in many of them.\n\nThe reason why I decided to make checkout co, is that we have already an\nalternative for checkout: switch. So unlike all those other VCS, in git\nwe can have:\n\n co = commit\n sw = switch\n\nOf course we would need to make switch actually usable, but that's a\nseprate task.\n\n-- \nFelipe Contreras\n"},{"id":"429023","messageId":"87wnq99fdd.fsf@igel.home","threadId":"56039","inReplyTo":"60dee7d4e27bf_2964b20817@natae.notmuch","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2021-07-02T10:31:10Z","receivedAt":"2021-07-02T10:31:19Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Jul 02 2021, Felipe Contreras wrote:\n\n> Andreas Schwab wrote:\n>> On Jul 02 2021, Felipe Contreras wrote:\n>> \n>> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n>> > index 340c5fbb48..32b1fdba45 100644\n>> > --- a/Documentation/git-commit.txt\n>> > +++ b/Documentation/git-commit.txt\n>> > @@ -17,6 +17,10 @@ SYNOPSIS\n>> > \t [(--trailer [(=|:)])...] [-S[]]\n>> > \t [--] [...]\n>> > \n>> > +ALIAS\n>> > +~~~~~\n>> > +'git co'\n>> \n>> That's `checkout' in hg, bzr, svn and cvs.\n>\n> I know, and commit is ci in many of them.\n\nWhat's the point of making git different if the goal is to make it\nsimilar? Everyone will associate co with checkout.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"429024","messageId":"60deee85f2786_744208cb@natae.notmuch","threadId":"56039","inReplyTo":"87wnq99fdd.fsf@igel.home","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:46:29Z","receivedAt":"2021-07-02T10:46:35Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andreas Schwab wrote:\n> On Jul 02 2021, Felipe Contreras wrote:\n> \n> > Andreas Schwab wrote:\n> >> On Jul 02 2021, Felipe Contreras wrote:\n> >> \n> >> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n> >> > index 340c5fbb48..32b1fdba45 100644\n> >> > --- a/Documentation/git-commit.txt\n> >> > +++ b/Documentation/git-commit.txt\n> >> > @@ -17,6 +17,10 @@ SYNOPSIS\n> >> > \t [(--trailer [(=|:)])...] [-S[]]\n> >> > \t [--] [...]\n> >> > \n> >> > +ALIAS\n> >> > +~~~~~\n> >> > +'git co'\n> >> \n> >> That's `checkout' in hg, bzr, svn and cvs.\n> >\n> > I know, and commit is ci in many of them.\n> \n> What's the point of making git different if the goal is to make it\n> similar?\n\nThe goal is not to make git identical to every other SCM; it's to take\nthe best ideas (not all of them).\n\n> Everyone will associate co with checkout.\n\nI don't think so. Fortunately there's other people in the mailing list\nthat can opine.\n\n-- \nFelipe Contreras\n"},{"id":"429025","messageId":"87o8bl9eb0.fsf@igel.home","threadId":"56039","inReplyTo":"60deee85f2786_744208cb@natae.notmuch","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2021-07-02T10:54:11Z","receivedAt":"2021-07-02T10:54:16Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Jul 02 2021, Felipe Contreras wrote:\n\n> Andreas Schwab wrote:\n>> On Jul 02 2021, Felipe Contreras wrote:\n>> \n>> > Andreas Schwab wrote:\n>> >> On Jul 02 2021, Felipe Contreras wrote:\n>> >> \n>> >> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n>> >> > index 340c5fbb48..32b1fdba45 100644\n>> >> > --- a/Documentation/git-commit.txt\n>> >> > +++ b/Documentation/git-commit.txt\n>> >> > @@ -17,6 +17,10 @@ SYNOPSIS\n>> >> > \t [(--trailer [(=|:)])...] [-S[]]\n>> >> > \t [--] [...]\n>> >> > \n>> >> > +ALIAS\n>> >> > +~~~~~\n>> >> > +'git co'\n>> >> \n>> >> That's `checkout' in hg, bzr, svn and cvs.\n>> >\n>> > I know, and commit is ci in many of them.\n>> \n>> What's the point of making git different if the goal is to make it\n>> similar?\n>\n> The goal is not to make git identical to every other SCM;\n\nI didn't say that.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"429026","messageId":"60def07e686c7_7442083a@natae.notmuch","threadId":"56039","inReplyTo":"65b1d215-c3ab-e0e3-f4ac-a30131541f9b@mfriebe.de","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:54:54Z","receivedAt":"2021-07-02T10:55:01Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"martin wrote:\n> On 02/07/2021 12:17, Felipe Contreras wrote:\n> > Andreas Schwab wrote:\n> >> On Jul 02 2021, Felipe Contreras wrote:\n> >>> +ALIAS\n> >>> +~~~~~\n> >>> +'git co'\n> >> That's `checkout' in hg, bzr, svn and cvs.\n> > I know, and commit is ci in many of them.\n> >\n> > The reason why I decided to make checkout co, is that we have already an\n> > alternative for checkout: switch. So unlike all those other VCS, in git\n> > we can have:\n> >\n> > co = commit\n> > sw = switch\n> >\n> \n> If I may jump into the discussion.\n> \n> IMHO it would be good to (partly) follow other vcs, and have\n> commit = ci\n\nI'm fine with leaving co out of the default aliases if it's deemed \"too\ncontroversial\".\n\nBut ci doesn't make sense. ci comes from \"check in\" which has no\nsimilitude in git.\n\nI don't think it's a good idea to leave \"git checkout\" without an alias\n(it's perhaps the second or third most used command), but at least some\naliases are better than no aliases.\n\n> 3) if co is not a default, then people can set it according to their own \n> taste, with less confusion, than if they override a default.\n\nPeople already have aliases. Whatever is the default doesn't matter.\nIf you don't like the default you can set a co alias to whatever you want.\n\n-- \nFelipe Contreras\n"},{"id":"429027","messageId":"3e82a574-fdcc-08b8-8fb5-1ff15f8ae564@mfriebe.de","threadId":"56039","inReplyTo":"60def07e686c7_7442083a@natae.notmuch","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"martin","fromEmail":"test2@mfriebe.de","sentAt":"2021-07-02T11:15:24Z","receivedAt":"2021-07-02T11:21:53Z","isPatch":true,"sender":{"key":"test2@mfriebe.de","avatar":null},"body":"On 02/07/2021 12:54, Felipe Contreras wrote:\n> martin wrote:\n>> IMHO it would be good to (partly) follow other vcs, and have\n>> commit = ci\n> I'm fine with leaving co out of the default aliases if it's deemed \"too\n> controversial\".\n>\n> But ci doesn't make sense. ci comes from \"check in\" which has no\n> similitude in git.\nsvn uses it for \"commit\".\nIt can be seen as CommIt.\n\nBut of course other letters can be picked. I don't see an advantage in \nit though.\nLike CoMmit cm ? or CommiT ct ? None of them seems any better to me.\n\n> I don't think it's a good idea to leave \"git checkout\" without an alias\n> (it's perhaps the second or third most used command), but at least some\n> aliases are better than no aliases.\nWell, that goes back to a bigger question. And from the brief time I \nhave been on this mail\nlist, it appears to me there is a divide into 2 groups.\n\nIf checkout is really meant to give way to switch/restore then it needs \nno further\nadvertising. And then the current usage statistics are a relict from the \nbefore switch/restore time.\n\nIf on the other hand checkout is not just to be kept for backward \ncompatibility, but should\nalways remain an equal alternative to switch/restore (i.e. it should \nstill be taught to new\nuser in 20 years) then it wants to have a default alias.\n\n"},{"id":"429032","messageId":"8735sxaqln.fsf@evledraar.gmail.com","threadId":"56039","inReplyTo":"20210702100506.1422429-6-felipe.contreras@gmail.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-02T11:32:48Z","receivedAt":"2021-07-02T11:43:20Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jul 02 2021, Felipe Contreras wrote:\n\n> These are all the aliases everyone agrees are essential.\n>\n> Virtually all VCS in the world have aliases, except git, so let's change\n> that.\n>\n> Signed-off-by: Felipe Contreras \n> ---\n> Documentation/git-branch.txt | 4 ++++\n> Documentation/git-cherry-pick.txt | 4 ++++\n> Documentation/git-commit.txt | 4 ++++\n> Documentation/git-mergetool.txt | 4 ++++\n> Documentation/git-rebase.txt | 4 ++++\n> Documentation/git-status.txt | 4 ++++\n> config.c | 29 +++++++++++++++++++++++++++++\n> config.h | 3 ++-\n> t/test-lib.sh | 2 ++\n> 9 files changed, 57 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\n> index 94dc9a54f2..fbf5ebd27a 100644\n> --- a/Documentation/git-branch.txt\n> +++ b/Documentation/git-branch.txt\n> @@ -24,6 +24,10 @@ SYNOPSIS\n> 'git branch' (-d | -D) [-r] ...\n> 'git branch' --edit-description []\n> \n> +ALIAS\n> +~~~~~\n> +'git br'\n\nI think for these it would be good to explicitly mention the mnemonic, e.g.:\n\n'git br', git 'br'anch. It's pretty obvious in this case, but not all of\nthem. This also addresses the '\"ci\" or \"co\"' discussion downthread\nsomewhat, i.e. at least we'll see if we always pick the first two\nletters, or if it's somewhat arbitrary.\n\n> +~~~~~\n> +'git pi'\n\nI've got this this as 'git chrp' locally FWIW, I'd think this would make\nmore sense if it was called 'git pick'.\n\n> +~~~~~\n> +'git co'\n\nNot going to wade into the downhtread co/ci discussion, except to say\nthat this is 'co'mmit, i.e. first two letters, like 'br'anch.\n\n> 'git mergetool' [--tool=] [-y | --[no-]prompt] [...]\n> \n> +ALIAS\n> +~~~~~\n> +'git mt'\n\nMaybe it's just me, but I don't think I've ever used git-mergetool\ndirectly. I don't think it's worthy of squatting on such a short name.\n\n> +ALIAS\n> +~~~~~\n> +'git rb'\n\nSo 'r'e'b'ase, not 're'base.\n\n> 'git status' [...] [--] [...]\n> \n> +ALIAS\n> +~~~~~\n> +'git st'\n\nFWIW I've got this aliased to 'git status --short', anyway, 'st'atus, so\nfirst two letters...\n\n> +static int git_config_default(config_fn_t fn, void *data)\n> +{\n> +\tint ret = 0;\n> +\tstruct config_source source;\n> +\n> +\tif (getenv(\"GIT_NO_DEFAULT_ALIASES\"))\n> +\t\treturn 0;\n\nCan't we just include this under GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS?\nMaybe rename it to GIT_TEST_DISALLOW_ABBREVIATED now that the \"OPTIONS\"\npart is considered inaccurate.\n\n> +\tmemset(&source, 0, sizeof(source));\n> +\tsource.prev = cf;\n> +\tsource.origin_type = CONFIG_ORIGIN_DEFAULT;\n> +\tcf = &source;\n> +\n> +\tret += fn(\"alias.co\", \"commit\", data);\n> +\tret += fn(\"alias.rb\", \"rebase\", data);\n> +\tret += fn(\"alias.st\", \"status\", data);\n> +\tret += fn(\"alias.br\", \"branch\", data);\n> +\tret += fn(\"alias.pi\", \"cherry-pick\", data);\n> +\tret += fn(\"alias.mt\", \"mergetool\", data);\n\nI haven't looked but does this also inject things into the configset\nAPI, or is it just going to be used by things that do\ngit_config_mycommand and fall back on git_config_default?\n\nAs long as the aliases mechanism picks it up I suppose it's fine.\n\n> static int config_parse_pair(const char *key, const char *value,\n> \t\t\t config_fn_t fn, void *data)\n> {\n> @@ -1897,6 +1921,9 @@ static int do_git_config_sequence(const struct config_options *opts,\n> \t\trepo_config = NULL;\n> \n> \tcurrent_parsing_scope = CONFIG_SCOPE_SYSTEM;\n> +\n> +\tgit_config_default(fn, data);\n> +\n> \tif (git_config_system() && system_config &&\n> \t !access_or_die(system_config, R_OK,\n> \t\t\t opts->system_gently ? ACCESS_EACCES_OK : 0))\n> @@ -3497,6 +3524,8 @@ const char *current_config_origin_type(void)\n> \t\treturn \"submodule-blob\";\n> \tcase CONFIG_ORIGIN_CMDLINE:\n> \t\treturn \"command line\";\n> +\tcase CONFIG_ORIGIN_DEFAULT:\n> +\t\treturn \"default\";\n> \tdefault:\n> \t\tBUG(\"unknown config origin type\");\n> \t}\n\nAh, this is likely it, do we incclude this in 'git config -l' etc? \n\n> diff --git a/config.h b/config.h\n> index 9038538ffd..bc3ecca313 100644\n> --- a/config.h\n> +++ b/config.h\n> @@ -58,7 +58,8 @@ enum config_origin_type {\n> \tCONFIG_ORIGIN_FILE,\n> \tCONFIG_ORIGIN_STDIN,\n> \tCONFIG_ORIGIN_SUBMODULE_BLOB,\n> -\tCONFIG_ORIGIN_CMDLINE\n> +\tCONFIG_ORIGIN_CMDLINE,\n> +\tCONFIG_ORIGIN_DEFAULT\n> };\n> \n> enum config_event_t {\n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index 49b80a4eb5..a15965e2f4 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -456,6 +456,8 @@ GIT_DEFAULT_HASH=\"${GIT_TEST_DEFAULT_HASH:-sha1}\"\n> export GIT_DEFAULT_HASH\n> GIT_TEST_MERGE_ALGORITHM=\"${GIT_TEST_MERGE_ALGORITHM:-ort}\"\n> export GIT_TEST_MERGE_ALGORITHM\n> +GIT_NO_DEFAULT_ALIASES=1\n> +export GIT_NO_DEFAULT_ALIASES\n> \n> # Tests using GIT_TRACE typically don't want : output\n> GIT_TRACE_BARE=1\n\nReally needs more tests.\n\nWe had some other thread where this was discussed where I suggested that\nwe implement some way to include default config. Ah, here it is:\nhttps://lore.kernel.org/git/87eedj74dr.fsf@evledraar.gmail.com/\n\nIt's more work for this, but I think it would really go a long way to\naddressing the concerns people are going to have about this.\n\nI think we should not opt-in to this from day one, but have some knob to\nenable including one of those shipped-by-default alias includes. Then\npeople could trivially mock svn/cvs or whatever their favorite VCS is,\nand eventually as people vote with their feed we could pick a canonical\none.\n"},{"id":"429041","messageId":"03a401d76f45$e1c6fce0$a554f6a0$@nexbridge.com","threadId":"56039","inReplyTo":"3e82a574-fdcc-08b8-8fb5-1ff15f8ae564@mfriebe.de","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-07-02T13:26:30Z","receivedAt":"2021-07-02T13:26:47Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 2, 2021 7:15 AM, martin wrote:\n>On 02/07/2021 12:54, Felipe Contreras wrote:\n>> martin wrote:\n>>> IMHO it would be good to (partly) follow other vcs, and have commit =\n>>> ci\n>> I'm fine with leaving co out of the default aliases if it's deemed\n>> \"too controversial\".\n>>\n>> But ci doesn't make sense. ci comes from \"check in\" which has no\n>> similitude in git.\n>svn uses it for \"commit\".\n>It can be seen as CommIt.\n>\n>But of course other letters can be picked. I don't see an advantage in it though.\n>Like CoMmit cm ? or CommiT ct ? None of them seems any better to me.\n>\n>> I don't think it's a good idea to leave \"git checkout\" without an\n>> alias (it's perhaps the second or third most used command), but at\n>> least some aliases are better than no aliases.\n>Well, that goes back to a bigger question. And from the brief time I have been on this mail list, it appears to me there is a divide into 2\n>groups.\n>\n>If checkout is really meant to give way to switch/restore then it needs no further advertising. And then the current usage statistics are a\n>relict from the before switch/restore time.\n>\n>If on the other hand checkout is not just to be kept for backward compatibility, but should always remain an equal alternative to\n>switch/restore (i.e. it should still be taught to new user in 20 years) then it wants to have a default alias.\n\nIn my opinion, default aliases are not a good path. If a command is intended to be part of the git command set, then it should be a builtin not an alias. Users have their own alias setups and implied conflicts are just going to be confusing and end up in help, examples, presentations, and so forth.\n\nIf you want a default alias set, publish it as part of an extension set, like the bash-completion, so that the user has to take action to install them in their environment. Do not do this in the base git product by default.\n\nFurther, if you are deprecating a command like checkout (which I know is not happening), then the command should go away rather than become an alias, unless a specific user wants to include this. That's what deprecation is. Keeping it around as an alias means you are keeping it around as a command, just providing a new access path.\n\nIf I was a committer on this project, I would have to be much more convinced that there is long-term value in this series than appears on the surface.\n\nI am sorry if I am coming across too strongly on this subject, but I do think we are overloading alias capability and intruding on a domain that should be reserved for our users, not ourselves.\n\nSincerely,\nRandall\n\n"},{"id":"429047","messageId":"874kdcal1k.fsf@evledraar.gmail.com","threadId":"56039","inReplyTo":"03a401d76f45$e1c6fce0$a554f6a0$@nexbridge.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-02T13:41:44Z","receivedAt":"2021-07-02T13:43:24Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jul 02 2021, Randall S. Becker wrote:\n\n> On July 2, 2021 7:15 AM, martin wrote:\n>>On 02/07/2021 12:54, Felipe Contreras wrote:\n>>> martin wrote:\n>>>> IMHO it would be good to (partly) follow other vcs, and have commit =\n>>>> ci\n>>> I'm fine with leaving co out of the default aliases if it's deemed\n>>> \"too controversial\".\n>>>\n>>> But ci doesn't make sense. ci comes from \"check in\" which has no\n>>> similitude in git.\n>>svn uses it for \"commit\".\n>>It can be seen as CommIt.\n>>\n>>But of course other letters can be picked. I don't see an advantage in it though.\n>>Like CoMmit cm ? or CommiT ct ? None of them seems any better to me.\n>>\n>>> I don't think it's a good idea to leave \"git checkout\" without an\n>>> alias (it's perhaps the second or third most used command), but at\n>>> least some aliases are better than no aliases.\n>>Well, that goes back to a bigger question. And from the brief time I have been on this mail list, it appears to me there is a divide into 2\n>>groups.\n>>\n>>If checkout is really meant to give way to switch/restore then it needs no further advertising. And then the current usage statistics are a\n>>relict from the before switch/restore time.\n>>\n>>If on the other hand checkout is not just to be kept for backward compatibility, but should always remain an equal alternative to\n>>switch/restore (i.e. it should still be taught to new user in 20 years) then it wants to have a default alias.\n>\n> In my opinion, default aliases are not a good path. If a command is\n> intended to be part of the git command set, then it should be a\n> builtin not an alias. Users have their own alias setups and implied\n> conflicts are just going to be confusing and end up in help, examples,\n> presentations, and so forth.\n\nSo aside from the \"are these aliases good idea?\" discussion, would you\nprefer if they're implemented that we theat them the exact same way we\ndo \"git fsck-objects\" and \"git fsck\"? I.e. list them twice in git.c,\njust pointing to the same cmd_fsck?\n"},{"id":"429050","messageId":"03ac01d76f4c$ad23a130$076ae390$@nexbridge.com","threadId":"56039","inReplyTo":"874kdcal1k.fsf@evledraar.gmail.com","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-07-02T14:15:08Z","receivedAt":"2021-07-02T14:15:24Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 2, 2021 9:42 AM, Ævar Arnfjörð Bjarmason wrote:\n>To: Randall S. Becker \n>Cc: 'martin' ; 'Felipe Contreras' ; 'Andreas Schwab' ;\n>git@vger.kernel.org; 'Junio C Hamano' \n>Subject: Re: [PATCH 5/5] config: add default aliases\n>\n>\n>On Fri, Jul 02 2021, Randall S. Becker wrote:\n>\n>> On July 2, 2021 7:15 AM, martin wrote:\n>>>On 02/07/2021 12:54, Felipe Contreras wrote:\n>>>> martin wrote:\n>>>>> IMHO it would be good to (partly) follow other vcs, and have commit\n>>>>> = ci\n>>>> I'm fine with leaving co out of the default aliases if it's deemed\n>>>> \"too controversial\".\n>>>>\n>>>> But ci doesn't make sense. ci comes from \"check in\" which has no\n>>>> similitude in git.\n>>>svn uses it for \"commit\".\n>>>It can be seen as CommIt.\n>>>\n>>>But of course other letters can be picked. I don't see an advantage in it though.\n>>>Like CoMmit cm ? or CommiT ct ? None of them seems any better to me.\n>>>\n>>>> I don't think it's a good idea to leave \"git checkout\" without an\n>>>> alias (it's perhaps the second or third most used command), but at\n>>>> least some aliases are better than no aliases.\n>>>Well, that goes back to a bigger question. And from the brief time I\n>>>have been on this mail list, it appears to me there is a divide into 2 groups.\n>>>\n>>>If checkout is really meant to give way to switch/restore then it\n>>>needs no further advertising. And then the current usage statistics are a relict from the before switch/restore time.\n>>>\n>>>If on the other hand checkout is not just to be kept for backward\n>>>compatibility, but should always remain an equal alternative to switch/restore (i.e. it should still be taught to new user in 20 years) then\n>it wants to have a default alias.\n>>\n>> In my opinion, default aliases are not a good path. If a command is\n>> intended to be part of the git command set, then it should be a\n>> builtin not an alias. Users have their own alias setups and implied\n>> conflicts are just going to be confusing and end up in help, examples,\n>> presentations, and so forth.\n>\n>So aside from the \"are these aliases good idea?\" discussion, would you prefer if they're implemented that we theat them the exact same\n>way we do \"git fsck-objects\" and \"git fsck\"? I.e. list them twice in git.c, just pointing to the same cmd_fsck?\n\nWithout knowing the full history of why the duplication, yes. That would be my preference. If it is a git command, it should be handled like one as closely as possible. Presumably, it also would show up in git help -a. I would not expect aliases to show in help.\n\n"},{"id":"429059","messageId":"xmqqr1ggpvxc.fsf@gitster.g","threadId":"56039","inReplyTo":"03a401d76f45$e1c6fce0$a554f6a0$@nexbridge.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-02T15:39:11Z","receivedAt":"2021-07-02T15:39:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" writes:\n\n> I am sorry if I am coming across too strongly on this subject, but\n> I do think we are overloading alias capability and intruding on a\n> domain that should be reserved for our users, not ourselves.\n\nWell said. The customization feature is for helping users, and we\nshouldn't get in their way by adding unnecessary ones ourselves.\n\nI wouldn't recommend us to force to our users even \"co is for\ncheckout\" that everybody seems to have. Adopting such a\ncustomization or not should be up to the users, and we should not\nget in the way of other users who may want to say \"co for me is\ncommit\".\n\nOne thing that might (or might not) help to help users and projects\nshare the same set of aliases is to make it easier to audit shared\nconfiguration file before inclusion. I wonder if would help to\nintroduce \"include.allow\" and \"include.block\" configuration variables\n\n [include] ;; or [includeIf \"\"]\n\tpath = /usr/share/git/contrib/svnlike.alias\n\tallow = alias.*\n\nthat tells us to only pay attention to the configuration keys that\nmatch these 'allow' patterns when reading from the given path.\n\nBut in practice, 'alias' is one of the riskier things you can set in\nthe configuration file, so it is of dubious value to say \"with this\nallow-list feature, you do not have to worry about random cruft\ndefined in the included path---you only need to concentrate on\nauditing alias.* configuration items in there and nothing else\".\n\n"},{"id":"429068","messageId":"65b1d215-c3ab-e0e3-f4ac-a30131541f9b@mfriebe.de","threadId":"56039","inReplyTo":"60dee7d4e27bf_2964b20817@natae.notmuch","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"martin","fromEmail":"test2@mfriebe.de","sentAt":"2021-07-02T10:44:00Z","receivedAt":"2021-07-02T19:59:17Z","isPatch":true,"sender":{"key":"test2@mfriebe.de","avatar":null},"body":"On 02/07/2021 12:17, Felipe Contreras wrote:\n> Andreas Schwab wrote:\n>> On Jul 02 2021, Felipe Contreras wrote:\n>>> +ALIAS\n>>> +~~~~~\n>>> +'git co'\n>> That's `checkout' in hg, bzr, svn and cvs.\n> I know, and commit is ci in many of them.\n>\n> The reason why I decided to make checkout co, is that we have already an\n> alternative for checkout: switch. So unlike all those other VCS, in git\n> we can have:\n>\n> co = commit\n> sw = switch\n>\n\nIf I may jump into the discussion.\n\nIMHO it would be good to (partly) follow other vcs, and have\ncommit = ci\n\nbut then keep\nswitch = sw\n\nAnd leave co empty.\n\nReasons for co not used:\n1) co would be CheckOut, and not switch. But checkout should be faded \nout and replaced by switch/restore\n2) co is ambiguous, in the sense that people coming from other vcs \nexpect checkout,\n    but people who started on git (especially who started with switch, \ninstead of checkout) expect commit.\n3) if co is not a default, then people can set it according to their own \ntaste, with less confusion, than if they override a default.\n\n"},{"id":"429069","messageId":"60df79ff7643b_28bb208ed@natae.notmuch","threadId":"56039","inReplyTo":"xmqqr1ggpvxc.fsf@gitster.g","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T20:41:35Z","receivedAt":"2021-07-02T20:41:40Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> \"Randall S. Becker\" writes:\n> \n> > I am sorry if I am coming across too strongly on this subject, but\n> > I do think we are overloading alias capability and intruding on a\n> > domain that should be reserved for our users, not ourselves.\n> \n> Well said. The customization feature is for helping users, and we\n> shouldn't get in their way by adding unnecessary ones ourselves.\n\nNobody is getting in their way, and if they are unnecessary why does\n*everyone* have aliases?\n\n> I wouldn't recommend us to force to our users even \"co is for\n> checkout\" that everybody seems to have.\n\nThey are not being forced.\n\n> One thing that might (or might not) help to help users and projects\n> share the same set of aliases is to make it easier to audit shared\n> configuration file before inclusion. I wonder if would help to\n> introduce \"include.allow\" and \"include.block\" configuration variables\n> \n> [include] ;; or [includeIf \"\"]\n> \tpath = /usr/share/git/contrib/svnlike.alias\n> \tallow = alias.*\n> \n> that tells us to only pay attention to the configuration keys that\n> match these 'allow' patterns when reading from the given path.\n\ncontrib is a black whole where nothing comes out of, so I would rather\nnot doom yet another useful feature to that fate.\n\n> But in practice, 'alias' is one of the riskier things you can set in\n> the configuration file,\n\nWhy?\n\n-- \nFelipe Contreras\n"},{"id":"429070","messageId":"60df7aa04575_28bb20875@natae.notmuch","threadId":"56039","inReplyTo":"8f847f31-5c5d-0236-997c-bd07040f7ea7@mfriebe.de","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T20:44:16Z","receivedAt":"2021-07-02T20:44:20Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"martin wrote:\n> On 02/07/2021 16:15, Randall S. Becker wrote:\n> > Without knowing the full history of why the duplication, yes. That\n> > would be my preference. If it is a git command, it should be handled\n> > like one as closely as possible. Presumably, it also would show up\n> > in git help -a. I would not expect aliases to show in help.\n> \n> But, if it is a git command, can you still overwrite it with your on\n> alias?\n\nNo, you won't. That's why they need to be implemented as aliases.\n\n-- \nFelipe Contreras\n"},{"id":"429071","messageId":"60df7ee3128d6_28bb2086c@natae.notmuch","threadId":"56039","inReplyTo":"03a401d76f45$e1c6fce0$a554f6a0$@nexbridge.com","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T21:02:27Z","receivedAt":"2021-07-02T21:02:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Randall S. Becker wrote:\n\n> In my opinion, default aliases are not a good path. If a command is\n> intended to be part of the git command set, then it should be a\n> builtin not an alias.\n\nCommands cannot be overriden, aliases can.\n\nAll SCM projects have aliases, except git. Why do you think that is?\n\n> Users have their own alias setups and implied conflicts are just going\n> to be confusing and end up in help, examples, presentations, and so\n> forth.\n\nThere's no conflict. Either you use the alias or you don't. Just like\ntoday.\n\n> If you want a default alias set, publish it as part of an extension\n> set, like the bash-completion, so that the user has to take action to\n> install them in their environment. Do not do this in the base git\n> product by default.\n\nThe whole point is to help users so they don't have to do extra\nconfigurations.\n\nToday git is pretty much unbearable without a configuration. Default\naliases would help quell some of that pain.\n\n> If I was a committer on this project, I would have to be much more\n> convinced that there is long-term value in this series than appears on\n> the surface.\n\n 1. It doesn't affect anyone negatively\n 2. You don't have to use them if you don't want to\n 3. They don't affect your aliases, even if they have the same name\n 4. Everyone has aliases\n 5. Every SCM in history has had aliases\n\nWhat more would you need?\n\n> I am sorry if I am coming across too strongly on this subject, but I\n> do think we are overloading alias capability and intruding on a domain\n> that should be reserved for our users, not ourselves.\n\nBut why? We provide plenty of defaults so that users don't have to\nconfigure git in order for the program to be useful. And we will\ncontinue to add more defaults.\n\n-- \nFelipe Contreras\n"},{"id":"429072","messageId":"60df813938303_28bb208c8@natae.notmuch","threadId":"56039","inReplyTo":"3e82a574-fdcc-08b8-8fb5-1ff15f8ae564@mfriebe.de","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T21:12:25Z","receivedAt":"2021-07-02T21:12:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"martin wrote:\n> On 02/07/2021 12:54, Felipe Contreras wrote:\n> > martin wrote:\n> >> IMHO it would be good to (partly) follow other vcs, and have\n> >> commit = ci\n> > I'm fine with leaving co out of the default aliases if it's deemed \"too\n> > controversial\".\n> >\n> > But ci doesn't make sense. ci comes from \"check in\" which has no\n> > similitude in git.\n> svn uses it for \"commit\".\n> It can be seen as CommIt.\n\nI know, but it comes from CVS.\n\nIn both CVS and Subversion \"commit\" pushes a commit, so it can be seen\nas the opposite of \"checkout\", which pulls a commit.\n\nThat's not the case in git.\n\n> But of course other letters can be picked. I don't see an advantage in \n> it though.\n\nThe advantage is that it's straightforward: co -> commit.\n\n> > I don't think it's a good idea to leave \"git checkout\" without an alias\n> > (it's perhaps the second or third most used command), but at least some\n> > aliases are better than no aliases.\n> Well, that goes back to a bigger question. And from the brief time I \n> have been on this mail\n> list, it appears to me there is a divide into 2 groups.\n\nI'm on neither of those camps.\n\n> If checkout is really meant to give way to switch/restore then it needs \n> no further\n> advertising. And then the current usage statistics are a relict from the \n> before switch/restore time.\n\nThis is what I think eventually should happen, but we are not there yet.\n\nIf checkout were to disappear today, I wouldn't be able to do a lot of\nthings. switch/restore are not ready yet.\n\n> If on the other hand checkout is not just to be kept for backward \n> compatibility, but should\n> always remain an equal alternative to switch/restore (i.e. it should \n> still be taught to new\n> user in 20 years) then it wants to have a default alias.\n\nWhy? Not all commands need an alias, only the most widely used. If\nswitch/restore can be used for 99% of use cases (not the case today),\nthen there's no need for checkout to have a default alias.\n\nOf course if somebody wants to keep using checkout instead of\nswitch/restore, they can add an alias themselves.\n\n\nI'm on the camp of \"let's see\".\n\n-- \nFelipe Contreras\n"},{"id":"429074","messageId":"8f847f31-5c5d-0236-997c-bd07040f7ea7@mfriebe.de","threadId":"56039","inReplyTo":"03ac01d76f4c$ad23a130$076ae390$@nexbridge.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"martin","fromEmail":"test2@mfriebe.de","sentAt":"2021-07-02T14:43:42Z","receivedAt":"2021-07-02T21:20:08Z","isPatch":true,"sender":{"key":"test2@mfriebe.de","avatar":null},"body":"On 02/07/2021 16:15, Randall S. Becker wrote:\n> On July 2, 2021 9:42 AM, Ævar Arnfjörð Bjarmason wrote:\n>> So aside from the \"are these aliases good idea?\" discussion, would \n>> you prefer if they're implemented that we theat them the exact same\n>> way we do \"git fsck-objects\" and \"git fsck\"? I.e. list them twice in git.c, just pointing to the same cmd_fsck?\n> Without knowing the full history of why the duplication, yes. That would be my preference. If it is a git command, it should be handled like one as closely as possible. Presumably, it also would show up in git help -a. I would not expect aliases to show in help.\n>\nBut, if it is a git command, can you still overwrite it with your on alias?\n\nAs it was pointed out, some of those are used by people as aliases for \nother things already.\n"},{"id":"429076","messageId":"cb40e459-7862-b917-b4bb-7bd6f929adef@mfriebe.de","threadId":"56039","inReplyTo":"60df813938303_28bb208c8@natae.notmuch","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"martin","fromEmail":"test2@mfriebe.de","sentAt":"2021-07-02T21:31:20Z","receivedAt":"2021-07-02T21:31:25Z","isPatch":true,"sender":{"key":"test2@mfriebe.de","avatar":null},"body":"On 02/07/2021 23:12, Felipe Contreras wrote:\n> I know, but it comes from CVS.\n>\n> In both CVS and Subversion \"commit\" pushes a commit, so it can be seen\n> as the opposite of \"checkout\", which pulls a commit.\n>\n> That's not the case in git.\n>\n>> But of course other letters can be picked. I don't see an advantage in\n>> it though.\n> The advantage is that it's straightforward: co -> commit.\n\nBut it is not that different between git and svn/cvs\n\nsvn/cvs both store/restore from the repository. That happens to be on \nthe server.\ngit  store/restore from the repository. That happens to be local. (the \nremote is optional in git)\n\n\nThat, said, it is ok to break with the old patterns. Otherwise \ninnovation can't happen.\nBut, plenty of users have old habits, and those die hard.\nIf the new aliases should help people, then those used to other meanings \nof the same alias may not think of it as that much help.\n\nAlso, git has plenty more commands than other vcs. Even if not all of \nthem will be aliased, people will expect different sub sets of them in \nthe list of those with alias.\nMaybe 3 letter aliases will be less controversial\ngit com\ngit cho (checkout if needs must)\ngit rst  restore\ngit swt  switch\n\n\n"},{"id":"429077","messageId":"74124ed2-2905-a167-90b6-9b289521ea83@mfriebe.de","threadId":"56039","inReplyTo":"60df7ee3128d6_28bb2086c@natae.notmuch","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"martin","fromEmail":"test2@mfriebe.de","sentAt":"2021-07-02T21:40:25Z","receivedAt":"2021-07-02T21:40:30Z","isPatch":true,"sender":{"key":"test2@mfriebe.de","avatar":null},"body":"On 02/07/2021 23:02, Felipe Contreras wrote:\n>\n>> If I was a committer on this project, I would have to be much more\n>> convinced that there is long-term value in this series than appears on\n>> the surface.\n> 1. It doesn't affect anyone negatively\n> 2. You don't have to use them if you don't want to\n> 3. They don't affect your aliases, even if they have the same name\n> 4. Everyone has aliases\n> 5. Every SCM in history has had aliases\n>\n> What more would you need?\n>\n\nWell, it might be good if they were configurable.\n\ncore.built-in-alias=false\ncore.built-in-alias=true\ncore.built-in-alias=sw,rs  # switch,restore\n\nAlso, it can be debated if they should be on or off by default. (hence \nbuilt-in)\n\nIf the setting is undefined, then if a user does\n    git sw branch\nIt will print:\nbuilt in aliases are not enabled. Please run\n   git config core.built-in-alias=true\n\nThat way no one is forced to anything, but they are easy to enable, and \nself advertising.\n\n"},{"id":"429079","messageId":"60df8c20e8518_28bb20846@natae.notmuch","threadId":"56039","inReplyTo":"8735sxaqln.fsf@evledraar.gmail.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T21:58:56Z","receivedAt":"2021-07-02T21:59:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Fri, Jul 02 2021, Felipe Contreras wrote:\n> \n> > These are all the aliases everyone agrees are essential.\n> >\n> > Virtually all VCS in the world have aliases, except git, so let's change\n> > that.\n> >\n> > Signed-off-by: Felipe Contreras \n> > ---\n> > Documentation/git-branch.txt | 4 ++++\n> > Documentation/git-cherry-pick.txt | 4 ++++\n> > Documentation/git-commit.txt | 4 ++++\n> > Documentation/git-mergetool.txt | 4 ++++\n> > Documentation/git-rebase.txt | 4 ++++\n> > Documentation/git-status.txt | 4 ++++\n> > config.c | 29 +++++++++++++++++++++++++++++\n> > config.h | 3 ++-\n> > t/test-lib.sh | 2 ++\n> > 9 files changed, 57 insertions(+), 1 deletion(-)\n> >\n> > diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\n> > index 94dc9a54f2..fbf5ebd27a 100644\n> > --- a/Documentation/git-branch.txt\n> > +++ b/Documentation/git-branch.txt\n> > @@ -24,6 +24,10 @@ SYNOPSIS\n> > 'git branch' (-d | -D) [-r] ...\n> > 'git branch' --edit-description []\n> > \n> > +ALIAS\n> > +~~~~~\n> > +'git br'\n> \n> I think for these it would be good to explicitly mention the mnemonic, e.g.:\n> \n> 'git br', git 'br'anch. It's pretty obvious in this case, but not all of\n> them.\n\nIf we are on `man git-branch(1)`, `git help branch`, or\n`git branch --help` I think it's pretty obvious what the alias is for.\n\nEspecially since it's right after the synopsis.\n\nFTR all other SCM's specify the alias directly. Perhaps we could even do\n'br' instead of 'git br'.\n\n> This also addresses the '\"ci\" or \"co\"' discussion downthread\n> somewhat, i.e. at least we'll see if we always pick the first two\n> letters, or if it's somewhat arbitrary.\n\nHow? What would be the mnemonic for 'ci'?\n\n> > +~~~~~\n> > +'git pi'\n> \n> I've got this this as 'git chrp' locally FWIW, I'd think this would make\n> more sense if it was called 'git pick'.\n\nYeah, but we are aiming for two letters the only other good option is\n'cp' which can be easily confused.\n\nFor a past discussion on this alias see [1].\n\n> > +~~~~~\n> > +'git co'\n> \n> Not going to wade into the downhtread co/ci discussion, except to say\n> that this is 'co'mmit, i.e. first two letters, like 'br'anch.\n\nYeap, so it's straightforward.\n\n> > 'git mergetool' [--tool=] [-y | --[no-]prompt] [...]\n> > \n> > +ALIAS\n> > +~~~~~\n> > +'git mt'\n> \n> Maybe it's just me, but I don't think I've ever used git-mergetool\n> directly. I don't think it's worthy of squatting on such a short name.\n\nHuh? How is a user supposed to jump from a merge failing to mergetool?\n(or rebase, or cherr-pick)\n\n> > +ALIAS\n> > +~~~~~\n> > +'git rb'\n> \n> So 'r'e'b'ase, not 're'base.\n\nI don't know if 're' makes more sense here.\n\n> > 'git status' [...] [--] [...]\n> > \n> > +ALIAS\n> > +~~~~~\n> > +'git st'\n> \n> FWIW I've got this aliased to 'git status --short', anyway, 'st'atus, so\n> first two letters...\n\nMe too. Actually --short --branch.\n\n> > +static int git_config_default(config_fn_t fn, void *data)\n> > +{\n> > +\tint ret = 0;\n> > +\tstruct config_source source;\n> > +\n> > +\tif (getenv(\"GIT_NO_DEFAULT_ALIASES\"))\n> > +\t\treturn 0;\n> \n> Can't we just include this under GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS?\n> Maybe rename it to GIT_TEST_DISALLOW_ABBREVIATED now that the \"OPTIONS\"\n> part is considered inaccurate.\n\nFine by me.\n\n> > +\tmemset(&source, 0, sizeof(source));\n> > +\tsource.prev = cf;\n> > +\tsource.origin_type = CONFIG_ORIGIN_DEFAULT;\n> > +\tcf = &source;\n> > +\n> > +\tret += fn(\"alias.co\", \"commit\", data);\n> > +\tret += fn(\"alias.rb\", \"rebase\", data);\n> > +\tret += fn(\"alias.st\", \"status\", data);\n> > +\tret += fn(\"alias.br\", \"branch\", data);\n> > +\tret += fn(\"alias.pi\", \"cherry-pick\", data);\n> > +\tret += fn(\"alias.mt\", \"mergetool\", data);\n> \n> I haven't looked but does this also inject things into the configset\n> API, or is it just going to be used by things that do\n> git_config_mycommand and fall back on git_config_default?\n\nI'm not sure what you mean. But it's basically as if you have them in\na config file.\n\nInitially I used a diffent approach but the bash completion did not pick\nthem up. This is as close to a config file as possible.\n\n> > static int config_parse_pair(const char *key, const char *value,\n> > \t\t\t config_fn_t fn, void *data)\n> > {\n> > @@ -1897,6 +1921,9 @@ static int do_git_config_sequence(const struct config_options *opts,\n> > \t\trepo_config = NULL;\n> > \n> > \tcurrent_parsing_scope = CONFIG_SCOPE_SYSTEM;\n> > +\n> > +\tgit_config_default(fn, data);\n> > +\n> > \tif (git_config_system() && system_config &&\n> > \t !access_or_die(system_config, R_OK,\n> > \t\t\t opts->system_gently ? ACCESS_EACCES_OK : 0))\n> > @@ -3497,6 +3524,8 @@ const char *current_config_origin_type(void)\n> > \t\treturn \"submodule-blob\";\n> > \tcase CONFIG_ORIGIN_CMDLINE:\n> > \t\treturn \"command line\";\n> > +\tcase CONFIG_ORIGIN_DEFAULT:\n> > +\t\treturn \"default\";\n> > \tdefault:\n> > \t\tBUG(\"unknown config origin type\");\n> > \t}\n> \n> Ah, this is likely it, do we incclude this in 'git config -l' etc? \n\nYes. Just like all other configurations.\n\n> > diff --git a/config.h b/config.h\n> > index 9038538ffd..bc3ecca313 100644\n> > --- a/config.h\n> > +++ b/config.h\n> > @@ -58,7 +58,8 @@ enum config_origin_type {\n> > \tCONFIG_ORIGIN_FILE,\n> > \tCONFIG_ORIGIN_STDIN,\n> > \tCONFIG_ORIGIN_SUBMODULE_BLOB,\n> > -\tCONFIG_ORIGIN_CMDLINE\n> > +\tCONFIG_ORIGIN_CMDLINE,\n> > +\tCONFIG_ORIGIN_DEFAULT\n> > };\n> > \n> > enum config_event_t {\n> > diff --git a/t/test-lib.sh b/t/test-lib.sh\n> > index 49b80a4eb5..a15965e2f4 100644\n> > --- a/t/test-lib.sh\n> > +++ b/t/test-lib.sh\n> > @@ -456,6 +456,8 @@ GIT_DEFAULT_HASH=\"${GIT_TEST_DEFAULT_HASH:-sha1}\"\n> > export GIT_DEFAULT_HASH\n> > GIT_TEST_MERGE_ALGORITHM=\"${GIT_TEST_MERGE_ALGORITHM:-ort}\"\n> > export GIT_TEST_MERGE_ALGORITHM\n> > +GIT_NO_DEFAULT_ALIASES=1\n> > +export GIT_NO_DEFAULT_ALIASES\n> > \n> > # Tests using GIT_TRACE typically don't want : output\n> > GIT_TRACE_BARE=1\n> \n> Really needs more tests.\n> \n> We had some other thread where this was discussed where I suggested that\n> we implement some way to include default config. Ah, here it is:\n> https://lore.kernel.org/git/87eedj74dr.fsf@evledraar.gmail.com/\n> \n> It's more work for this, but I think it would really go a long way to\n> addressing the concerns people are going to have about this.\n> \n> I think we should not opt-in to this from day one, but have some knob to\n> enable including one of those shipped-by-default alias includes. Then\n> people could trivially mock svn/cvs or whatever their favorite VCS is,\n> and eventually as people vote with their feed we could pick a canonical\n> one.\n\nAs I mentioned there the problem is where do we put that file, and how\ndo we distribute it.\n\nI think it's a cleaner approach, and we should definitely try it, but\nultimately it's not going to change the fact that these aliases should\nbe part of the distribution, especially if they are mentioned in the man\npages. So it would just be an alternative way of hardcoding them.\n\n[1] https://lore.kernel.org/git/20140421204506.GD5105@thunk.org/\n\n-- \nFelipe Contreras"},{"id":"429080","messageId":"03ce01d76f8d$b0cfa8b0$126efa10$@nexbridge.com","threadId":"56039","inReplyTo":"60df7ee3128d6_28bb2086c@natae.notmuch","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-07-02T22:00:32Z","receivedAt":"2021-07-02T22:00:47Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 2, 2021 5:02 PM, Felipe Contreras wrote:\n>To: Randall S. Becker ; 'martin' ; 'Felipe Contreras' ;\n>'Andreas Schwab' \n>Cc: git@vger.kernel.org; 'Ævar Arnfjörð Bjarmason' ; 'Junio C Hamano' \n>Subject: RE: [PATCH 5/5] config: add default aliases\n>\n>Randall S. Becker wrote:\n>\n>> In my opinion, default aliases are not a good path. If a command is\n>> intended to be part of the git command set, then it should be a\n>> builtin not an alias.\n>\n>Commands cannot be overriden, aliases can.\n>\n>All SCM projects have aliases, except git. Why do you think that is?\n\nI do not think my intent was conveyed. Default aliases made by the product provider, regardless of who that is, are not a good path. If I was RCS, I would not make an alias that everyone had to take. Same for git. git has aliases, but they are for the user. If the end-user team wants to implement a particular set of primitives for their environment, that's fantastic, and entirely possible in git. But I do not want to be constrained by someone else's primitives that are not core product.\n\n>> Users have their own alias setups and implied conflicts are just going\n>> to be confusing and end up in help, examples, presentations, and so\n>> forth.\n>\n>There's no conflict. Either you use the alias or you don't. Just like today.\n\nThen what is the point of this? I want my aliases, not someone else's. Again, if it is a core git alias, it is not an alias, it is a supported command and I should see it in the git help -a output.\n\n>> If you want a default alias set, publish it as part of an extension\n>> set, like the bash-completion, so that the user has to take action to\n>> install them in their environment. Do not do this in the base git\n>> product by default.\n>\n>The whole point is to help users so they don't have to do extra configurations.\n\nThe whole point is that a user team should give thought to the functional extensions they want, as a team, which is where aliases come in. We, as git contributors, should not be telling them what their extensions are.\n\n>Today git is pretty much unbearable without a configuration. Default aliases would help quell some of that pain.\n\nGit is entirely bearable particularly in my own pons and medulla. I have three bash aliases, two for log, one for removing tags and no git aliases and I am highly productive.\n\nWould that make ECLIPSE intolerable?\n\n>> If I was a committer on this project, I would have to be much more\n>> convinced that there is long-term value in this series than appears on\n>> the surface.\n>\n> 1. It doesn't affect anyone negatively\n> 2. You don't have to use them if you don't want to 3. They don't affect your aliases, even if they have the same name 4. Everyone has\n>aliases 5. Every SCM in history has had aliases\n>\n>What more would you need?\n>\n>> I am sorry if I am coming across too strongly on this subject, but I\n>> do think we are overloading alias capability and intruding on a domain\n>> that should be reserved for our users, not ourselves.\n>\n>But why? We provide plenty of defaults so that users don't have to configure git in order for the program to be useful. And we will\n>continue to add more defaults.\n\nI remain unconvinced and I found the assertion #5 somewhat specious and incorrect. SCCS and RCS use Shell aliases. There are no aliases in ClearCase. Granted Perforce has them, but that is not a sufficient differentiator to use that over git by any stretch.\n\nWhy are we trying to create a standard set of aliases? I do not like the RCS primitives - never did - as a base and would not use them. If the command set is not sufficient, then it should be extended. If it is sufficient but complex for some, *they* can create aliases. I come back to my point that a community-based set of alias extensions should be managed as a distinct Open Source product that can be cloned from some cloud service and maintained independently from git. There is nothing stopping that from happening, except perhaps for something like an include operation in .gitconfig, which I think would be either a really good idea, or subject to a CVE, or both.\n\nI've expressed my opinion, and it's not my decision to adopt this. So whatever happens, as long as it does not pollute my community's expectation of git. Although, providing aliases will handcuff future command naming.\n\n"},{"id":"429081","messageId":"03cf01d76f8e$0d8cf620$28a6e260$@nexbridge.com","threadId":"56039","inReplyTo":"8f847f31-5c5d-0236-997c-bd07040f7ea7@mfriebe.de","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-07-02T22:03:07Z","receivedAt":"2021-07-02T22:03:22Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 2, 2021 10:44 AM, martin wrote:\n>To: Randall S. Becker ; 'Ævar Arnfjörð Bjarmason' \n>Cc: 'Felipe Contreras' ; 'Andreas Schwab' ; git@vger.kernel.org; 'Junio C\n>Hamano' \n>Subject: Re: [PATCH 5/5] config: add default aliases\n>\n>On 02/07/2021 16:15, Randall S. Becker wrote:\n>> On July 2, 2021 9:42 AM, Ævar Arnfjörð Bjarmason wrote:\n>>> So aside from the \"are these aliases good idea?\" discussion, would\n>>> you prefer if they're implemented that we theat them the exact same\n>>> way we do \"git fsck-objects\" and \"git fsck\"? I.e. list them twice in git.c, just pointing to the same cmd_fsck?\n>> Without knowing the full history of why the duplication, yes. That would be my preference. If it is a git command, it should be handled\n>like one as closely as possible. Presumably, it also would show up in git help -a. I would not expect aliases to show in help.\n>>\n>But, if it is a git command, can you still overwrite it with your on alias?\n>\n>As it was pointed out, some of those are used by people as aliases for other things already.\n\nIf an alias overwrites/overrides a git command, I would expect NIST to have a proverbial cow and a CVE will be raised, probably by me.\n\nOverriding base product functionality with something that does something other than what is documented is a highly questionable practice.\n\n"},{"id":"429083","messageId":"60df8fcf71d11_28bb20873@natae.notmuch","threadId":"56039","inReplyTo":"cb40e459-7862-b917-b4bb-7bd6f929adef@mfriebe.de","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T22:14:39Z","receivedAt":"2021-07-02T22:14:43Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"martin wrote:\n> On 02/07/2021 23:12, Felipe Contreras wrote:\n> > I know, but it comes from CVS.\n> >\n> > In both CVS and Subversion \"commit\" pushes a commit, so it can be seen\n> > as the opposite of \"checkout\", which pulls a commit.\n> >\n> > That's not the case in git.\n> >\n> >> But of course other letters can be picked. I don't see an advantage in\n> >> it though.\n> > The advantage is that it's straightforward: co -> commit.\n> \n> But it is not that different between git and svn/cvs\n> \n> svn/cvs both store/restore from the repository. That happens to be on \n> the server.\n> git  store/restore from the repository. That happens to be local. (the \n> remote is optional in git)\n\nFair point.\n\nHowever, I don't think git actually checks out anything. If you see the\nEnglish definition [1] the CVS checkout can be thought of as checking\nout a book from the library; the item you check out is not part of the\nrepository afterwards. Git doesn't do that.\n\nEither way we could leave the 'co' alias pending to see what happens\nwith switch/restore, but my guess is that as time goes by 'checkout'\nwill be used less and less.\n\n> That, said, it is ok to break with the old patterns. Otherwise \n> innovation can't happen.\n> But, plenty of users have old habits, and those die hard.\n> If the new aliases should help people, then those used to other meanings \n> of the same alias may not think of it as that much help.\n\nRight, but not all users have old habits. Some were born after\nSubversion was created. An important decision such as default aliases\nshould look into the future, not the past.\n\n> Also, git has plenty more commands than other vcs. Even if not all of \n> them will be aliased, people will expect different sub sets of them in \n> the list of those with alias.\n> Maybe 3 letter aliases will be less controversial\n\nI don't think so. In my opinion the list of default aliases should be\nsmall, and for that two characters is fine.\n\nCheers.\n\n[1] https://www.merriam-webster.com/dictionary/checkout\n\n-- \nFelipe Contreras"},{"id":"429084","messageId":"60df9045d0825_28bb208eb@natae.notmuch","threadId":"56039","inReplyTo":"74124ed2-2905-a167-90b6-9b289521ea83@mfriebe.de","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T22:16:37Z","receivedAt":"2021-07-02T22:16:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"martin wrote:\n> On 02/07/2021 23:02, Felipe Contreras wrote:\n> >\n> >> If I was a committer on this project, I would have to be much more\n> >> convinced that there is long-term value in this series than appears on\n> >> the surface.\n> > 1. It doesn't affect anyone negatively\n> > 2. You don't have to use them if you don't want to\n> > 3. They don't affect your aliases, even if they have the same name\n> > 4. Everyone has aliases\n> > 5. Every SCM in history has had aliases\n> >\n> > What more would you need?\n> >\n> \n> Well, it might be good if they were configurable.\n\nWhat value does that provide?\n\n> That way no one is forced to anything, but they are easy to enable, and \n> self advertising.\n\nIf the default aliases were part of the git version you are using right\nnow I bet you wouldn't even notice.\n\n-- \nFelipe Contreras\n"},{"id":"429086","messageId":"60df93cfb0f44_28bb2084f@natae.notmuch","threadId":"56039","inReplyTo":"03ce01d76f8d$b0cfa8b0$126efa10$@nexbridge.com","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T22:31:43Z","receivedAt":"2021-07-02T22:31:49Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Randall S. Becker wrote:\n> On July 2, 2021 5:02 PM, Felipe Contreras wrote:\n> >To: Randall S. Becker ; 'martin' ; 'Felipe Contreras' ;\n> >'Andreas Schwab' \n> >Cc: git@vger.kernel.org; 'Ævar Arnfjörð Bjarmason' ; 'Junio C Hamano' \n> >Subject: RE: [PATCH 5/5] config: add default aliases\n> >\n> >Randall S. Becker wrote:\n> >\n> >> In my opinion, default aliases are not a good path. If a command is\n> >> intended to be part of the git command set, then it should be a\n> >> builtin not an alias.\n> >\n> >Commands cannot be overriden, aliases can.\n> >\n> >All SCM projects have aliases, except git. Why do you think that is?\n> \n> I do not think my intent was conveyed. Default aliases made by the\n> product provider, regardless of who that is, are not a good path.\n\nWhy?\n\n> If I was RCS, I would not make an alias that everyone had to take.\n\nNobody has to take them.\n\n> Same for git. git has aliases, but they are for the user. If the\n> end-user team wants to implement a particular set of primitives for\n> their environment, that's fantastic, and entirely possible in git. But\n> I do not want to be constrained by someone else's primitives that are\n> not core product.\n\nNobody is constrained.\n\n> >> Users have their own alias setups and implied conflicts are just going\n> >> to be confusing and end up in help, examples, presentations, and so\n> >> forth.\n> >\n> >There's no conflict. Either you use the alias or you don't. Just like today.\n> \n> Then what is the point of this? I want my aliases, not someone else's.\n\nThen use your aliases. This patch is not for you.\n\n> Again, if it is a core git alias, it is not an alias, it is a\n> supported command and I should see it in the git help -a output.\n\nA core git alias is an alias, and you will see them in the `git help -a`\noutput, in the aliases section.\n\n> >> If you want a default alias set, publish it as part of an extension\n> >> set, like the bash-completion, so that the user has to take action to\n> >> install them in their environment. Do not do this in the base git\n> >> product by default.\n> >\n> >The whole point is to help users so they don't have to do extra configurations.\n> \n> The whole point is that a user team should give thought to the\n> functional extensions they want, as a team, which is where aliases\n> come in.\n\nOnce again, this patch doesn't prevent anyone from doing anything.\n\n> We, as git contributors, should not be telling them what their extensions are.\n\nWe are not.\n\n> >Today git is pretty much unbearable without a configuration. Default aliases would help quell some of that pain.\n> \n> Git is entirely bearable particularly in my own pons and medulla.\n\nGood. But you are not the average user.\n\n> >> If I was a committer on this project, I would have to be much more\n> >> convinced that there is long-term value in this series than appears on\n> >> the surface.\n> >\n> > 1. It doesn't affect anyone negatively\n> > 2. You don't have to use them if you don't want to 3. They don't affect your aliases, even if they have the same name 4. Everyone has\n> >aliases 5. Every SCM in history has had aliases\n> >\n> >What more would you need?\n> >\n> >> I am sorry if I am coming across too strongly on this subject, but I\n> >> do think we are overloading alias capability and intruding on a domain\n> >> that should be reserved for our users, not ourselves.\n> >\n> >But why? We provide plenty of defaults so that users don't have to configure git in order for the program to be useful. And we will\n> >continue to add more defaults.\n> \n> I remain unconvinced and I found the assertion #5 somewhat specious\n> and incorrect. SCCS and RCS use Shell aliases.\n\n> There are no aliases in ClearCase.\n\nYes there are [1]:\n\n checkout | co [ –res/erved ] [–unr/eserved [ –nma/ ster ] ]\n\n> Granted Perforce has them, but that is not a sufficient differentiator\n> to use that over git by any stretch.\n\nAll the popular SCMs have them:\n\n * Mercurial\n * Subversion\n * CVS\n * Clearcase\n * Perforce\n\n> I've expressed my opinion, and it's not my decision to adopt this. So\n> whatever happens, as long as it does not pollute my community's\n> expectation of git. Although, providing aliases will handcuff future\n> command naming.\n\nThat's not true. Nothing is handcuffed.\n\n[1] https://www.ibm.com/docs/en/rational-clearcase/9.0.0?topic=ucm-checkout\n\n-- \nFelipe Contreras"},{"id":"429087","messageId":"60df941a7c43e_28bb20837@natae.notmuch","threadId":"56039","inReplyTo":"03cf01d76f8e$0d8cf620$28a6e260$@nexbridge.com","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T22:32:58Z","receivedAt":"2021-07-02T22:33:03Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Randall S. Becker wrote:\n> If an alias overwrites/overrides a git command, I would expect NIST to\n> have a proverbial cow and a CVE will be raised, probably by me.\n\nOnce again; that cannot happen.\n\n-- \nFelipe Contreras\n"},{"id":"429088","messageId":"5cbb845f-b8a6-939e-cf37-a3b375438616@mfriebe.de","threadId":"56039","inReplyTo":"60df8c20e8518_28bb20846@natae.notmuch","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"martin","fromEmail":"test2@mfriebe.de","sentAt":"2021-07-02T22:38:18Z","receivedAt":"2021-07-02T22:38:23Z","isPatch":true,"sender":{"key":"test2@mfriebe.de","avatar":null},"body":"On 02/07/2021 23:58, Felipe Contreras wrote:\n> Ævar Arnfjörð Bjarmason wrote:\n>>> +ALIAS\n>>> +~~~~~\n>>> +'git rb'\n>> So 'r'e'b'ase, not 're'base.\n> I don't know if 're' makes more sense here.\n\nre:\nrestore\nrebase\nreset\n\nAnd restore is on the level of checkout => so more important.\n"},{"id":"429091","messageId":"60dfa5e28158a_3dd2208b9@natae.notmuch","threadId":"56039","inReplyTo":"5cbb845f-b8a6-939e-cf37-a3b375438616@mfriebe.de","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T23:48:50Z","receivedAt":"2021-07-02T23:48:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"martin wrote:\n> On 02/07/2021 23:58, Felipe Contreras wrote:\n> > Ævar Arnfjörð Bjarmason wrote:\n> >>> +ALIAS\n> >>> +~~~~~\n> >>> +'git rb'\n> >> So 'r'e'b'ase, not 're'base.\n> > I don't know if 're' makes more sense here.\n> \n> re:\n> restore\n> rebase\n> reset\n> \n> And restore is on the level of checkout => so more important.\n\nRight. Although we don't need to have aliases for all of them it's good\nto be consistent, so perhaps:\n\n rb => rebase\n rs => reset\n rt => restore\n\nI don't use restore (yet), but it's probably the one most people would\nuse most regularly, so maybe 're' instead of 'rt'.\n\n-- \nFelipe Contreras"},{"id":"429109","messageId":"YOBA6s7wXUVmh++d@coredump.intra.peff.net","threadId":"56039","inReplyTo":"20210702100506.1422429-6-felipe.contreras@gmail.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-07-03T10:50:18Z","receivedAt":"2021-07-03T10:50:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 02, 2021 at 05:05:06AM -0500, Felipe Contreras wrote:\n\n> These are all the aliases everyone agrees are essential.\n> \n> Virtually all VCS in the world have aliases, except git, so let's change\n> that.\n\nFor anyone reviewing or discussing, here's an older thread on the same\ntopic:\n\n https://lore.kernel.org/git/1379791221-29925-1-git-send-email-felipe.contreras@gmail.com/\n\n(I don't mean to imply that we can't revisit old decisions; but some of\nthe thoughts there are worth considering as input).\n\n-Peff\n"},{"id":"429240","messageId":"044e01d771a6$7c8cefc0$75a6cf40$@nexbridge.com","threadId":"56039","inReplyTo":"5cbb845f-b8a6-939e-cf37-a3b375438616@mfriebe.de","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-07-05T14:02:57Z","receivedAt":"2021-07-05T14:03:19Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 2, 2021 6:38 PM, martin wrote:\n>To: Felipe Contreras ; Ævar Arnfjörð Bjarmason \n>Cc: git@vger.kernel.org; Junio C Hamano \n>Subject: Re: [PATCH 5/5] config: add default aliases\n>\n>On 02/07/2021 23:58, Felipe Contreras wrote:\n>> Ævar Arnfjörð Bjarmason wrote:\n>>>> +ALIAS\n>>>> +~~~~~\n>>>> +'git rb'\n>>> So 'r'e'b'ase, not 're'base.\n>> I don't know if 're' makes more sense here.\n>\n>re:\n>restore\n>rebase\n>reset\n>\n>And restore is on the level of checkout => so more important.\n\nI do not want anything helping out the use of rebase, which we actively discourage in our shop - except for rebase --autosquash to fix up topic branches for delivery. git 're' is certainly not helpful.\n\nFrom an earlier suggestion, why not just put all of your desired aliases in its own file somewhere and reference them through a construct in .gitconfig like:\n\ninclude=\"/path/to/alias-config\"\n\nwhich would have to be implemented, but that decouples alias definitions from core git code and allows sharing of the definitions by a team without impinging on anyone else. I have great trepidation that users are going to start writing scripts using these aliases. I am going to be implementing a team standards document that would cause any use of aliases in scripts to fail code reviews - in fact, I'm looking to implement a commit hook that rejects the use of aliases in scripts that are committed.\n\n"},{"id":"429294","messageId":"04b901d7727b$67f62f10$37e28d30$@nexbridge.com","threadId":"56039","inReplyTo":"044e01d771a6$7c8cefc0$75a6cf40$@nexbridge.com","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-07-06T15:27:12Z","receivedAt":"2021-07-06T15:27:26Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 5, 2021 10:03 AM, I wrote:\n>On July 2, 2021 6:38 PM, martin wrote:\n>>To: Felipe Contreras ; Ævar Arnfjörð Bjarmason \n>>Cc: git@vger.kernel.org; Junio C Hamano \n>>Subject: Re: [PATCH 5/5] config: add default aliases\n>>\n>>On 02/07/2021 23:58, Felipe Contreras wrote:\n>>> Ævar Arnfjörð Bjarmason wrote:\n>>>>> +ALIAS\n>>>>> +~~~~~\n>>>>> +'git rb'\n>>>> So 'r'e'b'ase, not 're'base.\n>>> I don't know if 're' makes more sense here.\n>>\n>>re:\n>>restore\n>>rebase\n>>reset\n>>\n>>And restore is on the level of checkout => so more important.\n>\n>I do not want anything helping out the use of rebase, which we actively discourage in our shop - except for rebase --autosquash to fix up\n>topic branches for delivery. git 're' is certainly not helpful.\n>\n>>From an earlier suggestion, why not just put all of your desired aliases in its own file somewhere and reference them through a construct\n>in .gitconfig like:\n>\n>include=\"/path/to/alias-config\"\n>\n>which would have to be implemented, but that decouples alias definitions from core git code and allows sharing of the definitions by a\n>team without impinging on anyone else. I have great trepidation that users are going to start writing scripts using these aliases. I am\n>going to be implementing a team standards document that would cause any use of aliases in scripts to fail code reviews - in fact, I'm\n>looking to implement a commit hook that rejects the use of aliases in scripts that are committed.\n\nThis is already in place in .gitconfig:\n\n[include]\n\tpath = /path/to/git-aliases\n\nSo whatever a team's alias set needs to be can be completely decoupled from git and put into its own repo, and delivered to the team that way. I'm going to recommend that my team uses this for alias management instead of this patch set.\n\n-Randall\n\n"},{"id":"429363","messageId":"60e4d10bd8127_1c428120848@natae.notmuch","threadId":"56039","inReplyTo":"YOBA6s7wXUVmh++d@coredump.intra.peff.net","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-06T21:54:19Z","receivedAt":"2021-07-06T21:54:23Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Fri, Jul 02, 2021 at 05:05:06AM -0500, Felipe Contreras wrote:\n> \n> > These are all the aliases everyone agrees are essential.\n> > \n> > Virtually all VCS in the world have aliases, except git, so let's change\n> > that.\n> \n> For anyone reviewing or discussing, here's an older thread on the same\n> topic:\n> \n> https://lore.kernel.org/git/1379791221-29925-1-git-send-email-felipe.contreras@gmail.com/\n> \n> (I don't mean to imply that we can't revisit old decisions; but some of\n> the thoughts there are worth considering as input).\n\nRe-reading that thread--and filtering all the noise--the two thoughts\nthat I think are worth considering are:\n\n 1. A default alias might leak into some unofficial documentation, and\n people with a different alias could be surprised after typing that\n command and finding out it does a different thing.\n\n 2. A person might be used to an alias doing one thing, move to a\n different machine, and be surprised that the default alias does a\n diffrent thing.\n\nBut as mentioned in that thread those two are *existing* issues. People\nusing certain configurations (not even aliases) are surprised when the\nsame command does a different thing. And also people use their aliases\nin unofficial documentation already.\n\nDefault aliases would in fact make the situation less worse because if\none of these aliases leaks into unofficial documentation, there's a\nhigher chance that the command will do what was intended.\n\nThe counter-arguments were not addressed, so the conclussion is that\ndefault aliases would *not* make the existing problems worse.\n\n\nThat being said, there's ways to mitigate these problems, for example we\ncould add an avdice stating that a default alias is currently being\nused, something like:\n\n hint: You are using a default alias: co -> checkout.\n hint:\n hint: If you want to incorporate this alias into your personal\n hint: aliases, type:\n hint:\n hint: git config --global alias.co checkout\n hint:\n hint: Disable this message with \"git config advice.defaultaliases false\"\n\nThere's many other ways to mitigate the issues. It would be in the best\ninerest of the probject to explore all these possibilities to their full\nextent instead of just throwing the towel and stay in the current\nundesirable state.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"429367","messageId":"60e4d250efe67_1c4281208f3@natae.notmuch","threadId":"56039","inReplyTo":"044e01d771a6$7c8cefc0$75a6cf40$@nexbridge.com","subject":"RE: [PATCH 5/5] config: add default aliases","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-06T21:59:44Z","receivedAt":"2021-07-06T21:59:58Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Randall S. Becker wrote:\n> On July 2, 2021 6:38 PM, martin wrote:\n> >To: Felipe Contreras ; Ævar Arnfjörð Bjarmason \n> >Cc: git@vger.kernel.org; Junio C Hamano \n> >Subject: Re: [PATCH 5/5] config: add default aliases\n> >\n> >On 02/07/2021 23:58, Felipe Contreras wrote:\n> >> Ævar Arnfjörð Bjarmason wrote:\n> >>>> +ALIAS\n> >>>> +~~~~~\n> >>>> +'git rb'\n> >>> So 'r'e'b'ase, not 're'base.\n> >> I don't know if 're' makes more sense here.\n> >\n> >re:\n> >restore\n> >rebase\n> >reset\n> >\n> >And restore is on the level of checkout => so more important.\n> \n> I do not want anything helping out the use of rebase, which we actively discourage in our shop\n\nThat is a problem specific for your shop.\n\nThe defaults are meant for the majority of users. If a minority of users\n(who happen to be working under the same umbrella) have a problem with\nthe defaults, they can change the defaults.\n\n-- \nFelipe Contreras"},{"id":"429634","messageId":"fac9cb8b-90e2-d6fc-2382-629e3a345756@iee.email","threadId":"56039","inReplyTo":"044e01d771a6$7c8cefc0$75a6cf40$@nexbridge.com","subject":"Re: [PATCH 5/5] config: add default aliases","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-07-10T15:30:54Z","receivedAt":"2021-07-10T15:31:00Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 05/07/2021 15:02, Randall S. Becker wrote:\n> I do not want anything helping out the use of rebase, which we in our shop - except for rebase --autosquash to fix up topic branches for delivery.\n\nI was wondering what the background/context to the 'actively discourage'\nis? \n\nI'd have expected that some in-place rework (i.e. rebase) could happen\nbefore code review, with possible further rework beyond simple\nfixup/squash commits being possible after review (if demanded), but with\nthe same fork-point (rather than following movements in the 'upstream'),\nrather similar to Git's development. i.e. Is it that the fork-point\nshouldn't be moved without good reason and permission, or something else?\n\njust wondering...\n\n--\nPhilip\n"}]}