[PATCH 0/5] Default aliases

[PATCH 0/5] Default aliases

[Felipe Contreras]

Virtually all VCS in history have default aliases, except git. Let's
fix that.

To make the aliases uncontroversial all of them have to follow certain
rules:

 1) Each default alias should have two characters
 2) Each default alias should map to a command without arguments
 3) Each default alias be widely used in the wild

The list of default aliases on this series have been discussed before,
and even Junio stated "I think it might be OK to implement them" [1].
Since git is virtually unusable without aliases, it's an imperative to
make it useful by default.

Additionally, users should be able to override the default aliases
without any issue.

[1] https://lore.kernel.org/git/xmqqtx9m8obr.fsf@gitster.dls.corp.google.com/

Felipe Contreras (5):
  test: add missing whitespaces
  config: trivial style fix
  config: trivial struct initialization cleanup
  config: initialize origin_type correctly
  config: add default aliases

 Documentation/git-branch.txt      |  4 +++
 Documentation/git-cherry-pick.txt |  4 +++
 Documentation/git-commit.txt      |  4 +++
 Documentation/git-mergetool.txt   |  4 +++
 Documentation/git-rebase.txt      |  4 +++
 Documentation/git-status.txt      |  4 +++
 config.c                          | 44 +++++++++++++++++++++++++------
 config.h                          |  3 ++-
 t/t1300-config.sh                 |  1 +
 t/test-lib.sh                     |  3 +++
 10 files changed, 66 insertions(+), 9 deletions(-)

-- 
2.32.0.94.g4574ca548c

[PATCH 1/5] test: add missing whitespaces

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 t/t1300-config.sh | 1 +
 t/test-lib.sh     | 1 +
 2 files changed, 2 insertions(+)

diff --git a/t/t1300-config.sh b/t/t1300-config.sh
index 9ff46f3b04..453222b32f 100755
--- a/t/t1300-config.sh
+++ b/t/t1300-config.sh
@@ -335,6 +335,7 @@ test_expect_success 'working --list' '
 	git config --list > output &&
 	test_cmp expect output
 '
+
 test_expect_success '--list without repo produces empty output' '
 	git --git-dir=nonexistent config --list >output &&
 	test_must_be_empty output
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 54938c6427..49b80a4eb5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -430,6 +430,7 @@ unset VISUAL EMAIL LANGUAGE COLUMNS $("$PERL_PATH" -e '
 	my @vars = grep(/^GIT_/ && !/^GIT_($ok)/o, @env);
 	print join("\n", @vars);
 ')
+
 unset XDG_CACHE_HOME
 unset XDG_CONFIG_HOME
 unset GITPERLLIB
-- 
2.32.0.94.g4574ca548c

[PATCH 2/5] config: trivial style fix

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 config.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.c b/config.c
index f9c400ad30..dc896c434e 100644
--- a/config.c
+++ b/config.c
@@ -3482,7 +3482,7 @@ const char *current_config_origin_type(void)
 	int type;
 	if (current_config_kvi)
 		type = current_config_kvi->origin_type;
-	else if(cf)
+	else if (cf)
 		type = cf->origin_type;
 	else
 		BUG("current_config_origin_type called outside config callback");
-- 
2.32.0.94.g4574ca548c

[PATCH 3/5] config: trivial struct initialization cleanup

[Felipe Contreras]

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 config.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/config.c b/config.c
index dc896c434e..9172c96c54 100644
--- a/config.c
+++ b/config.c
@@ -2265,11 +2265,11 @@ int git_configset_get_pathname(struct config_set *cs, const char *key, const cha
 /* Functions use to read configuration from a repository */
 static void repo_read_config(struct repository *repo)
 {
-	struct config_options opts = { 0 };
-
-	opts.respect_includes = 1;
-	opts.commondir = repo->commondir;
-	opts.git_dir = repo->gitdir;
+	struct config_options opts = {
+		.respect_includes = 1,
+		.commondir = repo->commondir,
+		.git_dir = repo->gitdir,
+	};
 
 	if (!repo->config)
 		CALLOC_ARRAY(repo->config, 1);
-- 
2.32.0.94.g4574ca548c

[PATCH 4/5] config: initialize origin_type correctly

[Felipe Contreras]

cf->origin_type either is CONFIG_ORIGIN_CMDLINE, or it's something else.

Don't override that.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 config.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/config.c b/config.c
index 9172c96c54..666fb2c689 100644
--- a/config.c
+++ b/config.c
@@ -2087,13 +2087,12 @@ static int configset_add_value(struct config_set *cs, const char *key, const cha
 	if (cf->name) {
 		kv_info->filename = strintern(cf->name);
 		kv_info->linenr = cf->linenr;
-		kv_info->origin_type = cf->origin_type;
 	} else {
 		/* for values read from `git_config_from_parameters()` */
 		kv_info->filename = NULL;
 		kv_info->linenr = -1;
-		kv_info->origin_type = CONFIG_ORIGIN_CMDLINE;
 	}
+	kv_info->origin_type = cf->origin_type;
 	kv_info->scope = current_parsing_scope;
 	si->util = kv_info;
 
-- 
2.32.0.94.g4574ca548c

[PATCH 5/5] config: add default aliases

[Felipe Contreras]

These are all the aliases everyone agrees are essential.

Virtually all VCS in the world have aliases, except git, so let's change
that.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Documentation/git-branch.txt      |  4 ++++
 Documentation/git-cherry-pick.txt |  4 ++++
 Documentation/git-commit.txt      |  4 ++++
 Documentation/git-mergetool.txt   |  4 ++++
 Documentation/git-rebase.txt      |  4 ++++
 Documentation/git-status.txt      |  4 ++++
 config.c                          | 29 +++++++++++++++++++++++++++++
 config.h                          |  3 ++-
 t/test-lib.sh                     |  2 ++
 9 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 94dc9a54f2..fbf5ebd27a 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -24,6 +24,10 @@ SYNOPSIS
 'git branch' (-d | -D) [-r] <branchname>...
 'git branch' --edit-description [<branchname>]
 
+ALIAS
+~~~~~
+'git br'
+
 DESCRIPTION
 -----------
 
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 5d750314b2..b43b1a3a30 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -12,6 +12,10 @@ SYNOPSIS
 		  [-S[<keyid>]] <commit>...
 'git cherry-pick' (--continue | --skip | --abort | --quit)
 
+ALIAS
+~~~~~
+'git pi'
+
 DESCRIPTION
 -----------
 
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 340c5fbb48..32b1fdba45 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -17,6 +17,10 @@ SYNOPSIS
 	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
 	   [--] [<pathspec>...]
 
+ALIAS
+~~~~~
+'git co'
+
 DESCRIPTION
 -----------
 Create a new commit containing the current contents of the index and
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index e587c7763a..59708a1f3e 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -10,6 +10,10 @@ SYNOPSIS
 [verse]
 'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
 
+ALIAS
+~~~~~
+'git mt'
+
 DESCRIPTION
 -----------
 
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 55af6fd24e..21f5ae9d0e 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -14,6 +14,10 @@ SYNOPSIS
 	--root [<branch>]
 'git rebase' (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)
 
+ALIAS
+~~~~~
+'git rb'
+
 DESCRIPTION
 -----------
 If <branch> is specified, 'git rebase' will perform an automatic
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 83f38e3198..fcc89fa8d4 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -11,6 +11,10 @@ SYNOPSIS
 [verse]
 'git status' [<options>...] [--] [<pathspec>...]
 
+ALIAS
+~~~~~
+'git st'
+
 DESCRIPTION
 -----------
 Displays paths that have differences between the index file and the
diff --git a/config.c b/config.c
index 666fb2c689..c42f41599c 100644
--- a/config.c
+++ b/config.c
@@ -501,6 +501,30 @@ int git_config_key_is_valid(const char *key)
 	return !git_config_parse_key_1(key, NULL, NULL, 1);
 }
 
+static int git_config_default(config_fn_t fn, void *data)
+{
+	int ret = 0;
+	struct config_source source;
+
+	if (getenv("GIT_NO_DEFAULT_ALIASES"))
+		return 0;
+
+	memset(&source, 0, sizeof(source));
+	source.prev = cf;
+	source.origin_type = CONFIG_ORIGIN_DEFAULT;
+	cf = &source;
+
+	ret += fn("alias.co", "commit", data);
+	ret += fn("alias.rb", "rebase", data);
+	ret += fn("alias.st", "status", data);
+	ret += fn("alias.br", "branch", data);
+	ret += fn("alias.pi", "cherry-pick", data);
+	ret += fn("alias.mt", "mergetool", data);
+
+	cf = source.prev;
+	return ret;
+}
+
 static int config_parse_pair(const char *key, const char *value,
 			  config_fn_t fn, void *data)
 {
@@ -1897,6 +1921,9 @@ static int do_git_config_sequence(const struct config_options *opts,
 		repo_config = NULL;
 
 	current_parsing_scope = CONFIG_SCOPE_SYSTEM;
+
+	git_config_default(fn, data);
+
 	if (git_config_system() && system_config &&
 	    !access_or_die(system_config, R_OK,
 			   opts->system_gently ? ACCESS_EACCES_OK : 0))
@@ -3497,6 +3524,8 @@ const char *current_config_origin_type(void)
 		return "submodule-blob";
 	case CONFIG_ORIGIN_CMDLINE:
 		return "command line";
+	case CONFIG_ORIGIN_DEFAULT:
+		return "default";
 	default:
 		BUG("unknown config origin type");
 	}
diff --git a/config.h b/config.h
index 9038538ffd..bc3ecca313 100644
--- a/config.h
+++ b/config.h
@@ -58,7 +58,8 @@ enum config_origin_type {
 	CONFIG_ORIGIN_FILE,
 	CONFIG_ORIGIN_STDIN,
 	CONFIG_ORIGIN_SUBMODULE_BLOB,
-	CONFIG_ORIGIN_CMDLINE
+	CONFIG_ORIGIN_CMDLINE,
+	CONFIG_ORIGIN_DEFAULT
 };
 
 enum config_event_t {
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 49b80a4eb5..a15965e2f4 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -456,6 +456,8 @@ GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-sha1}"
 export GIT_DEFAULT_HASH
 GIT_TEST_MERGE_ALGORITHM="${GIT_TEST_MERGE_ALGORITHM:-ort}"
 export GIT_TEST_MERGE_ALGORITHM
+GIT_NO_DEFAULT_ALIASES=1
+export GIT_NO_DEFAULT_ALIASES
 
 # Tests using GIT_TRACE typically don't want <timestamp> <file>:<line> output
 GIT_TRACE_BARE=1
-- 
2.32.0.94.g4574ca548c

Re: [PATCH 5/5] config: add default aliases

[Andreas Schwab]

On Jul 02 2021, Felipe Contreras wrote:

> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index 340c5fbb48..32b1fdba45 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -17,6 +17,10 @@ SYNOPSIS
>  	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
>  	   [--] [<pathspec>...]
>  
> +ALIAS
> +~~~~~
> +'git co'

That's `checkout' in hg, bzr, svn and cvs.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Andreas Schwab wrote:
> On Jul 02 2021, Felipe Contreras wrote:
> 
> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> > index 340c5fbb48..32b1fdba45 100644
> > --- a/Documentation/git-commit.txt
> > +++ b/Documentation/git-commit.txt
> > @@ -17,6 +17,10 @@ SYNOPSIS
> >  	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
> >  	   [--] [<pathspec>...]
> >  
> > +ALIAS
> > +~~~~~
> > +'git co'
> 
> That's `checkout' in hg, bzr, svn and cvs.

I know, and commit is ci in many of them.

The reason why I decided to make checkout co, is that we have already an
alternative for checkout: switch. So unlike all those other VCS, in git
we can have:

  co = commit
  sw = switch

Of course we would need to make switch actually usable, but that's a
seprate task.

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[Andreas Schwab]

On Jul 02 2021, Felipe Contreras wrote:

> Andreas Schwab wrote:
>> On Jul 02 2021, Felipe Contreras wrote:
>> 
>> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
>> > index 340c5fbb48..32b1fdba45 100644
>> > --- a/Documentation/git-commit.txt
>> > +++ b/Documentation/git-commit.txt
>> > @@ -17,6 +17,10 @@ SYNOPSIS
>> >  	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
>> >  	   [--] [<pathspec>...]
>> >  
>> > +ALIAS
>> > +~~~~~
>> > +'git co'
>> 
>> That's `checkout' in hg, bzr, svn and cvs.
>
> I know, and commit is ci in many of them.

What's the point of making git different if the goal is to make it
similar?  Everyone will associate co with checkout.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Andreas Schwab wrote:
> On Jul 02 2021, Felipe Contreras wrote:
> 
> > Andreas Schwab wrote:
> >> On Jul 02 2021, Felipe Contreras wrote:
> >> 
> >> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> >> > index 340c5fbb48..32b1fdba45 100644
> >> > --- a/Documentation/git-commit.txt
> >> > +++ b/Documentation/git-commit.txt
> >> > @@ -17,6 +17,10 @@ SYNOPSIS
> >> >  	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
> >> >  	   [--] [<pathspec>...]
> >> >  
> >> > +ALIAS
> >> > +~~~~~
> >> > +'git co'
> >> 
> >> That's `checkout' in hg, bzr, svn and cvs.
> >
> > I know, and commit is ci in many of them.
> 
> What's the point of making git different if the goal is to make it
> similar?

The goal is not to make git identical to every other SCM; it's to take
the best ideas (not all of them).

> Everyone will associate co with checkout.

I don't think so. Fortunately there's other people in the mailing list
that can opine.

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[Andreas Schwab]

On Jul 02 2021, Felipe Contreras wrote:

> Andreas Schwab wrote:
>> On Jul 02 2021, Felipe Contreras wrote:
>> 
>> > Andreas Schwab wrote:
>> >> On Jul 02 2021, Felipe Contreras wrote:
>> >> 
>> >> > diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
>> >> > index 340c5fbb48..32b1fdba45 100644
>> >> > --- a/Documentation/git-commit.txt
>> >> > +++ b/Documentation/git-commit.txt
>> >> > @@ -17,6 +17,10 @@ SYNOPSIS
>> >> >  	   [(--trailer <token>[(=|:)<value>])...] [-S[<keyid>]]
>> >> >  	   [--] [<pathspec>...]
>> >> >  
>> >> > +ALIAS
>> >> > +~~~~~
>> >> > +'git co'
>> >> 
>> >> That's `checkout' in hg, bzr, svn and cvs.
>> >
>> > I know, and commit is ci in many of them.
>> 
>> What's the point of making git different if the goal is to make it
>> similar?
>
> The goal is not to make git identical to every other SCM;

I didn't say that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH 5/5] config: add default aliases

[martin]

On 02/07/2021 12:17, Felipe Contreras wrote:
> Andreas Schwab wrote:
>> On Jul 02 2021, Felipe Contreras wrote:
>>> +ALIAS
>>> +~~~~~
>>> +'git co'
>> That's `checkout' in hg, bzr, svn and cvs.
> I know, and commit is ci in many of them.
>
> The reason why I decided to make checkout co, is that we have already an
> alternative for checkout: switch. So unlike all those other VCS, in git
> we can have:
>
>    co = commit
>    sw = switch
>

If I may jump into the discussion.

IMHO it would be good to (partly) follow other vcs, and have
commit = ci

but then keep
switch = sw

And leave co empty.

Reasons for co not used:
1) co would be CheckOut, and not switch. But checkout should be faded 
out and replaced by switch/restore
2) co is ambiguous, in the sense that people coming from other vcs 
expect checkout,
    but people who started on git (especially who started with switch, 
instead of checkout) expect commit.
3) if co is not a default, then people can set it according to their own 
taste, with less confusion, than if they override a default.

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

martin wrote:
> On 02/07/2021 12:17, Felipe Contreras wrote:
> > Andreas Schwab wrote:
> >> On Jul 02 2021, Felipe Contreras wrote:
> >>> +ALIAS
> >>> +~~~~~
> >>> +'git co'
> >> That's `checkout' in hg, bzr, svn and cvs.
> > I know, and commit is ci in many of them.
> >
> > The reason why I decided to make checkout co, is that we have already an
> > alternative for checkout: switch. So unlike all those other VCS, in git
> > we can have:
> >
> >    co = commit
> >    sw = switch
> >
> 
> If I may jump into the discussion.
> 
> IMHO it would be good to (partly) follow other vcs, and have
> commit = ci

I'm fine with leaving co out of the default aliases if it's deemed "too
controversial".

But ci doesn't make sense. ci comes from "check in" which has no
similitude in git.

I don't think it's a good idea to leave "git checkout" without an alias
(it's perhaps the second or third most used command), but at least some
aliases are better than no aliases.

> 3) if co is not a default, then people can set it according to their own 
> taste, with less confusion, than if they override a default.

People already have aliases. Whatever is the default doesn't matter.
If you don't like the default you can set a co alias to whatever you want.

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[martin]

On 02/07/2021 12:54, Felipe Contreras wrote:
> martin wrote:
>> IMHO it would be good to (partly) follow other vcs, and have
>> commit = ci
> I'm fine with leaving co out of the default aliases if it's deemed "too
> controversial".
>
> But ci doesn't make sense. ci comes from "check in" which has no
> similitude in git.
svn uses it for "commit".
It can be seen as CommIt.

But of course other letters can be picked. I don't see an advantage in 
it though.
Like CoMmit cm ? or CommiT ct ? None of them seems any better to me.

> I don't think it's a good idea to leave "git checkout" without an alias
> (it's perhaps the second or third most used command), but at least some
> aliases are better than no aliases.
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 groups.

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 relict from the 
before switch/restore time.

If on the other hand checkout is not just to be kept for backward 
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 it wants to have a default alias.

RE: [PATCH 5/5] config: add default aliases

[Randall S. Becker]

On July 2, 2021 7:15 AM, martin wrote:
>On 02/07/2021 12:54, Felipe Contreras wrote:
>> martin wrote:
>>> IMHO it would be good to (partly) follow other vcs, and have commit =
>>> ci
>> I'm fine with leaving co out of the default aliases if it's deemed
>> "too controversial".
>>
>> But ci doesn't make sense. ci comes from "check in" which has no
>> similitude in git.
>svn uses it for "commit".
>It can be seen as CommIt.
>
>But of course other letters can be picked. I don't see an advantage in it though.
>Like CoMmit cm ? or CommiT ct ? None of them seems any better to me.
>
>> I don't think it's a good idea to leave "git checkout" without an
>> alias (it's perhaps the second or third most used command), but at
>> least some aliases are better than no aliases.
>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
>groups.
>
>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
>relict from the before switch/restore time.
>
>If on the other hand checkout is not just to be kept for backward 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 it wants to have a default alias.

In 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.

If 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.

Further, 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.

If 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.

I 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.

Sincerely,
Randall

Re: [PATCH 5/5] config: add default aliases

[Ævar Arnfjörð Bjarmason]

On Fri, Jul 02 2021, Randall S. Becker wrote:

> On July 2, 2021 7:15 AM, martin wrote:
>>On 02/07/2021 12:54, Felipe Contreras wrote:
>>> martin wrote:
>>>> IMHO it would be good to (partly) follow other vcs, and have commit =
>>>> ci
>>> I'm fine with leaving co out of the default aliases if it's deemed
>>> "too controversial".
>>>
>>> But ci doesn't make sense. ci comes from "check in" which has no
>>> similitude in git.
>>svn uses it for "commit".
>>It can be seen as CommIt.
>>
>>But of course other letters can be picked. I don't see an advantage in it though.
>>Like CoMmit cm ? or CommiT ct ? None of them seems any better to me.
>>
>>> I don't think it's a good idea to leave "git checkout" without an
>>> alias (it's perhaps the second or third most used command), but at
>>> least some aliases are better than no aliases.
>>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
>>groups.
>>
>>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
>>relict from the before switch/restore time.
>>
>>If on the other hand checkout is not just to be kept for backward 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 it wants to have a default alias.
>
> In 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.

So aside from the "are these aliases good idea?" discussion, would you
prefer if they're implemented that we theat them the exact same way we
do "git fsck-objects" and "git fsck"? I.e. list them twice in git.c,
just pointing to the same cmd_fsck?

RE: [PATCH 5/5] config: add default aliases

[Randall S. Becker]

On July 2, 2021 9:42 AM, Ævar Arnfjörð Bjarmason wrote:
>To: Randall S. Becker <rsbecker@nexbridge.com>
>Cc: 'martin' <test2@mfriebe.de>; 'Felipe Contreras' <felipe.contreras@gmail.com>; 'Andreas Schwab' <schwab@linux-m68k.org>;
>git@vger.kernel.org; 'Junio C Hamano' <gitster@pobox.com>
>Subject: Re: [PATCH 5/5] config: add default aliases
>
>
>On Fri, Jul 02 2021, Randall S. Becker wrote:
>
>> On July 2, 2021 7:15 AM, martin wrote:
>>>On 02/07/2021 12:54, Felipe Contreras wrote:
>>>> martin wrote:
>>>>> IMHO it would be good to (partly) follow other vcs, and have commit
>>>>> = ci
>>>> I'm fine with leaving co out of the default aliases if it's deemed
>>>> "too controversial".
>>>>
>>>> But ci doesn't make sense. ci comes from "check in" which has no
>>>> similitude in git.
>>>svn uses it for "commit".
>>>It can be seen as CommIt.
>>>
>>>But of course other letters can be picked. I don't see an advantage in it though.
>>>Like CoMmit cm ? or CommiT ct ? None of them seems any better to me.
>>>
>>>> I don't think it's a good idea to leave "git checkout" without an
>>>> alias (it's perhaps the second or third most used command), but at
>>>> least some aliases are better than no aliases.
>>>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 groups.
>>>
>>>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 relict from the before switch/restore time.
>>>
>>>If on the other hand checkout is not just to be kept for backward
>>>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
>it wants to have a default alias.
>>
>> In 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.
>
>So aside from the "are these aliases good idea?" discussion, would you prefer if they're implemented that we theat them the exact same
>way we do "git fsck-objects" and "git fsck"? I.e. list them twice in git.c, just pointing to the same cmd_fsck?

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.

Re: [PATCH 5/5] config: add default aliases

[martin]

On 02/07/2021 16:15, Randall S. Becker wrote:
> On July 2, 2021 9:42 AM, Ævar Arnfjörð Bjarmason wrote:
>> So aside from the "are these aliases good idea?" discussion, would 
>> you prefer if they're implemented that we theat them the exact same
>> way we do "git fsck-objects" and "git fsck"? I.e. list them twice in git.c, just pointing to the same cmd_fsck?
> 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.
>
But, if it is a git command, can you still overwrite it with your on alias?

As it was pointed out, some of those are used by people as aliases for 
other things already.

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

martin wrote:
> On 02/07/2021 16:15, Randall S. Becker wrote:
> > 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.
> 
> But, if it is a git command, can you still overwrite it with your on
> alias?

No, you won't. That's why they need to be implemented as aliases.

-- 
Felipe Contreras

RE: [PATCH 5/5] config: add default aliases

[Randall S. Becker]

On July 2, 2021 10:44 AM, martin wrote:
>To: Randall S. Becker <rsbecker@nexbridge.com>; 'Ævar Arnfjörð Bjarmason' <avarab@gmail.com>
>Cc: 'Felipe Contreras' <felipe.contreras@gmail.com>; 'Andreas Schwab' <schwab@linux-m68k.org>; git@vger.kernel.org; 'Junio C
>Hamano' <gitster@pobox.com>
>Subject: Re: [PATCH 5/5] config: add default aliases
>
>On 02/07/2021 16:15, Randall S. Becker wrote:
>> On July 2, 2021 9:42 AM, Ævar Arnfjörð Bjarmason wrote:
>>> So aside from the "are these aliases good idea?" discussion, would
>>> you prefer if they're implemented that we theat them the exact same
>>> way we do "git fsck-objects" and "git fsck"? I.e. list them twice in git.c, just pointing to the same cmd_fsck?
>> 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.
>>
>But, if it is a git command, can you still overwrite it with your on alias?
>
>As it was pointed out, some of those are used by people as aliases for other things already.

If 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.

Overriding base product functionality with something that does something other than what is documented is a highly questionable practice.

RE: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Randall S. Becker wrote:
> If 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.

Once again; that cannot happen.

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> I 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.

Well said.  The customization feature is for helping users, and we
shouldn't get in their way by adding unnecessary ones ourselves.

I wouldn't recommend us to force to our users even "co is for
checkout" that everybody seems to have.  Adopting such a
customization or not should be up to the users, and we should not
get in the way of other users who may want to say "co for me is
commit".

One thing that might (or might not) help to help users and projects
share the same set of aliases is to make it easier to audit shared
configuration file before inclusion.  I wonder if would help to
introduce "include.allow" and "include.block" configuration variables

    [include] ;; or [includeIf "<condition>"]
	path = /usr/share/git/contrib/svnlike.alias
	allow = alias.*

that tells us to only pay attention to the configuration keys that
match these 'allow' patterns when reading from the given path.

But in practice, 'alias' is one of the riskier things you can set in
the configuration file, so it is of dubious value to say "with this
allow-list feature, you do not have to worry about random cruft
defined in the included path---you only need to concentrate on
auditing alias.* configuration items in there and nothing else".

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> > I 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.
> 
> Well said.  The customization feature is for helping users, and we
> shouldn't get in their way by adding unnecessary ones ourselves.

Nobody is getting in their way, and if they are unnecessary why does
*everyone* have aliases?

> I wouldn't recommend us to force to our users even "co is for
> checkout" that everybody seems to have.

They are not being forced.

> One thing that might (or might not) help to help users and projects
> share the same set of aliases is to make it easier to audit shared
> configuration file before inclusion.  I wonder if would help to
> introduce "include.allow" and "include.block" configuration variables
> 
>     [include] ;; or [includeIf "<condition>"]
> 	path = /usr/share/git/contrib/svnlike.alias
> 	allow = alias.*
> 
> that tells us to only pay attention to the configuration keys that
> match these 'allow' patterns when reading from the given path.

contrib is a black whole where nothing comes out of, so I would rather
not doom yet another useful feature to that fate.

> But in practice, 'alias' is one of the riskier things you can set in
> the configuration file,

Why?

-- 
Felipe Contreras

RE: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Randall S. Becker wrote:

> In 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.

Commands cannot be overriden, aliases can.

All SCM projects have aliases, except git. Why do you think that is?

> 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.

There's no conflict. Either you use the alias or you don't. Just like
today.

> If 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.

The whole point is to help users so they don't have to do extra
configurations.

Today git is pretty much unbearable without a configuration. Default
aliases would help quell some of that pain.

> If 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.

 1. It doesn't affect anyone negatively
 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 aliases
 5. Every SCM in history has had aliases

What more would you need?

> I 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.

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
continue to add more defaults.

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[martin]

On 02/07/2021 23:02, Felipe Contreras wrote:
>
>> If 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.
>   1. It doesn't affect anyone negatively
>   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 aliases
>   5. Every SCM in history has had aliases
>
> What more would you need?
>

Well, it might be good if they were configurable.

core.built-in-alias=false
core.built-in-alias=true
core.built-in-alias=sw,rs  # switch,restore

Also, it can be debated if they should be on or off by default. (hence 
built-in)

If the setting is undefined, then if a user does
    git sw branch
It will print:
built in aliases are not enabled. Please run
   git config core.built-in-alias=true

That way no one is forced to anything, but they are easy to enable, and 
self advertising.

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

martin wrote:
> On 02/07/2021 23:02, Felipe Contreras wrote:
> >
> >> If 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.
> >   1. It doesn't affect anyone negatively
> >   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 aliases
> >   5. Every SCM in history has had aliases
> >
> > What more would you need?
> >
> 
> Well, it might be good if they were configurable.

What value does that provide?

> That way no one is forced to anything, but they are easy to enable, and 
> self advertising.

If the default aliases were part of the git version you are using right
now I bet you wouldn't even notice.

-- 
Felipe Contreras

RE: [PATCH 5/5] config: add default aliases

[Randall S. Becker]

On July 2, 2021 5:02 PM, Felipe Contreras wrote:
>To: Randall S. Becker <rsbecker@nexbridge.com>; 'martin' <test2@mfriebe.de>; 'Felipe Contreras' <felipe.contreras@gmail.com>;
>'Andreas Schwab' <schwab@linux-m68k.org>
>Cc: git@vger.kernel.org; 'Ævar Arnfjörð Bjarmason' <avarab@gmail.com>; 'Junio C Hamano' <gitster@pobox.com>
>Subject: RE: [PATCH 5/5] config: add default aliases
>
>Randall S. Becker wrote:
>
>> In 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.
>
>Commands cannot be overriden, aliases can.
>
>All SCM projects have aliases, except git. Why do you think that is?

I 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.

>> 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.
>
>There's no conflict. Either you use the alias or you don't. Just like today.

Then 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.

>> If 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.
>
>The whole point is to help users so they don't have to do extra configurations.

The 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.

>Today git is pretty much unbearable without a configuration. Default aliases would help quell some of that pain.

Git 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.

Would that make ECLIPSE intolerable?

>> If 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.
>
> 1. It doesn't affect anyone negatively
> 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
>aliases  5. Every SCM in history has had aliases
>
>What more would you need?
>
>> I 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.
>
>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
>continue to add more defaults.

I 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.

Why 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.

I'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.

RE: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Randall S. Becker wrote:
> On July 2, 2021 5:02 PM, Felipe Contreras wrote:
> >To: Randall S. Becker <rsbecker@nexbridge.com>; 'martin' <test2@mfriebe.de>; 'Felipe Contreras' <felipe.contreras@gmail.com>;
> >'Andreas Schwab' <schwab@linux-m68k.org>
> >Cc: git@vger.kernel.org; 'Ævar Arnfjörð Bjarmason' <avarab@gmail.com>; 'Junio C Hamano' <gitster@pobox.com>
> >Subject: RE: [PATCH 5/5] config: add default aliases
> >
> >Randall S. Becker wrote:
> >
> >> In 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.
> >
> >Commands cannot be overriden, aliases can.
> >
> >All SCM projects have aliases, except git. Why do you think that is?
> 
> I do not think my intent was conveyed. Default aliases made by the
> product provider, regardless of who that is, are not a good path.

Why?

> If I was RCS, I would not make an alias that everyone had to take.

Nobody has to take them.

> 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.

Nobody is constrained.

> >> 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.
> >
> >There's no conflict. Either you use the alias or you don't. Just like today.
> 
> Then what is the point of this? I want my aliases, not someone else's.

Then use your aliases. This patch is not for you.

> 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.

A core git alias is an alias, and you will see them in the `git help -a`
output, in the aliases section.

> >> If 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.
> >
> >The whole point is to help users so they don't have to do extra configurations.
> 
> The 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.

Once again, this patch doesn't prevent anyone from doing anything.

> We, as git contributors, should not be telling them what their extensions are.

We are not.

> >Today git is pretty much unbearable without a configuration. Default aliases would help quell some of that pain.
> 
> Git is entirely bearable particularly in my own pons and medulla.

Good. But you are not the average user.

> >> If 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.
> >
> > 1. It doesn't affect anyone negatively
> > 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
> >aliases  5. Every SCM in history has had aliases
> >
> >What more would you need?
> >
> >> I 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.
> >
> >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
> >continue to add more defaults.
> 
> I remain unconvinced and I found the assertion #5 somewhat specious
> and incorrect. SCCS and RCS use Shell aliases.

> There are no aliases in ClearCase.

Yes there are [1]:

  checkout | co [ –res/erved ] [–unr/eserved [ –nma/ ster ] ]

> Granted Perforce has them, but that is not a sufficient differentiator
> to use that over git by any stretch.

All the popular SCMs have them:

 * Mercurial
 * Subversion
 * CVS
 * Clearcase
 * Perforce

> I'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.

That's not true. Nothing is handcuffed.

[1] https://www.ibm.com/docs/en/rational-clearcase/9.0.0?topic=ucm-checkout

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

martin wrote:
> On 02/07/2021 12:54, Felipe Contreras wrote:
> > martin wrote:
> >> IMHO it would be good to (partly) follow other vcs, and have
> >> commit = ci
> > I'm fine with leaving co out of the default aliases if it's deemed "too
> > controversial".
> >
> > But ci doesn't make sense. ci comes from "check in" which has no
> > similitude in git.
> svn uses it for "commit".
> It can be seen as CommIt.

I know, but it comes from CVS.

In both CVS and Subversion "commit" pushes a commit, so it can be seen
as the opposite of "checkout", which pulls a commit.

That's not the case in git.

> But of course other letters can be picked. I don't see an advantage in 
> it though.

The advantage is that it's straightforward: co -> commit.

> > I don't think it's a good idea to leave "git checkout" without an alias
> > (it's perhaps the second or third most used command), but at least some
> > aliases are better than no aliases.
> 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 groups.

I'm on neither of those camps.

> 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 relict from the 
> before switch/restore time.

This is what I think eventually should happen, but we are not there yet.

If checkout were to disappear today, I wouldn't be able to do a lot of
things. switch/restore are not ready yet.

> If on the other hand checkout is not just to be kept for backward 
> 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 it wants to have a default alias.

Why? Not all commands need an alias, only the most widely used. If
switch/restore can be used for 99% of use cases (not the case today),
then there's no need for checkout to have a default alias.

Of course if somebody wants to keep using checkout instead of
switch/restore, they can add an alias themselves.


I'm on the camp of "let's see".

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[martin]

On 02/07/2021 23:12, Felipe Contreras wrote:
> I know, but it comes from CVS.
>
> In both CVS and Subversion "commit" pushes a commit, so it can be seen
> as the opposite of "checkout", which pulls a commit.
>
> That's not the case in git.
>
>> But of course other letters can be picked. I don't see an advantage in
>> it though.
> The advantage is that it's straightforward: co -> commit.

But it is not that different between git and svn/cvs

svn/cvs both store/restore from the repository. That happens to be on 
the server.
git  store/restore from the repository. That happens to be local. (the 
remote is optional in git)


That, said, it is ok to break with the old patterns. Otherwise 
innovation can't happen.
But, plenty of users have old habits, and those die hard.
If the new aliases should help people, then those used to other meanings 
of the same alias may not think of it as that much help.

Also, git has plenty more commands than other vcs. Even if not all of 
them will be aliased, people will expect different sub sets of them in 
the list of those with alias.
Maybe 3 letter aliases will be less controversial
git com
git cho (checkout if needs must)
git rst  restore
git swt  switch

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

martin wrote:
> On 02/07/2021 23:12, Felipe Contreras wrote:
> > I know, but it comes from CVS.
> >
> > In both CVS and Subversion "commit" pushes a commit, so it can be seen
> > as the opposite of "checkout", which pulls a commit.
> >
> > That's not the case in git.
> >
> >> But of course other letters can be picked. I don't see an advantage in
> >> it though.
> > The advantage is that it's straightforward: co -> commit.
> 
> But it is not that different between git and svn/cvs
> 
> svn/cvs both store/restore from the repository. That happens to be on 
> the server.
> git  store/restore from the repository. That happens to be local. (the 
> remote is optional in git)

Fair point.

However, I don't think git actually checks out anything. If you see the
English definition [1] the CVS checkout can be thought of as checking
out a book from the library; the item you check out is not part of the
repository afterwards. Git doesn't do that.

Either way we could leave the 'co' alias pending to see what happens
with switch/restore, but my guess is that as time goes by 'checkout'
will be used less and less.

> That, said, it is ok to break with the old patterns. Otherwise 
> innovation can't happen.
> But, plenty of users have old habits, and those die hard.
> If the new aliases should help people, then those used to other meanings 
> of the same alias may not think of it as that much help.

Right, but not all users have old habits. Some were born after
Subversion was created. An important decision such as default aliases
should look into the future, not the past.

> Also, git has plenty more commands than other vcs. Even if not all of 
> them will be aliased, people will expect different sub sets of them in 
> the list of those with alias.
> Maybe 3 letter aliases will be less controversial

I don't think so. In my opinion the list of default aliases should be
small, and for that two characters is fine.

Cheers.

[1] https://www.merriam-webster.com/dictionary/checkout

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[Ævar Arnfjörð Bjarmason]

On Fri, Jul 02 2021, Felipe Contreras wrote:

> These are all the aliases everyone agrees are essential.
>
> Virtually all VCS in the world have aliases, except git, so let's change
> that.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  Documentation/git-branch.txt      |  4 ++++
>  Documentation/git-cherry-pick.txt |  4 ++++
>  Documentation/git-commit.txt      |  4 ++++
>  Documentation/git-mergetool.txt   |  4 ++++
>  Documentation/git-rebase.txt      |  4 ++++
>  Documentation/git-status.txt      |  4 ++++
>  config.c                          | 29 +++++++++++++++++++++++++++++
>  config.h                          |  3 ++-
>  t/test-lib.sh                     |  2 ++
>  9 files changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> index 94dc9a54f2..fbf5ebd27a 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -24,6 +24,10 @@ SYNOPSIS
>  'git branch' (-d | -D) [-r] <branchname>...
>  'git branch' --edit-description [<branchname>]
>  
> +ALIAS
> +~~~~~
> +'git br'

I think for these it would be good to explicitly mention the mnemonic, e.g.:

'git br', git 'br'anch. It's pretty obvious in this case, but not all of
them. This also addresses the '"ci" or "co"' discussion downthread
somewhat, i.e. at least we'll see if we always pick the first two
letters, or if it's somewhat arbitrary.

> +~~~~~
> +'git pi'

I've got this this as 'git chrp' locally FWIW, I'd think this would make
more sense if it was called 'git pick'.

> +~~~~~
> +'git co'

Not going to wade into the downhtread co/ci discussion, except to say
that this is 'co'mmit, i.e. first two letters, like 'br'anch.

>  'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
>  
> +ALIAS
> +~~~~~
> +'git mt'

Maybe it's just me, but I don't think I've ever used git-mergetool
directly. I don't think it's worthy of squatting on such a short name.

> +ALIAS
> +~~~~~
> +'git rb'

So 'r'e'b'ase, not 're'base.

>  'git status' [<options>...] [--] [<pathspec>...]
>  
> +ALIAS
> +~~~~~
> +'git st'

FWIW I've got this aliased to 'git status --short', anyway, 'st'atus, so
first two letters...

> +static int git_config_default(config_fn_t fn, void *data)
> +{
> +	int ret = 0;
> +	struct config_source source;
> +
> +	if (getenv("GIT_NO_DEFAULT_ALIASES"))
> +		return 0;

Can't we just include this under GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS?
Maybe rename it to GIT_TEST_DISALLOW_ABBREVIATED now that the "OPTIONS"
part is considered inaccurate.

> +	memset(&source, 0, sizeof(source));
> +	source.prev = cf;
> +	source.origin_type = CONFIG_ORIGIN_DEFAULT;
> +	cf = &source;
> +
> +	ret += fn("alias.co", "commit", data);
> +	ret += fn("alias.rb", "rebase", data);
> +	ret += fn("alias.st", "status", data);
> +	ret += fn("alias.br", "branch", data);
> +	ret += fn("alias.pi", "cherry-pick", data);
> +	ret += fn("alias.mt", "mergetool", data);

I haven't looked but does this also inject things into the configset
API, or is it just going to be used by things that do
git_config_mycommand and fall back on git_config_default?

As long as the aliases mechanism picks it up I suppose it's fine.

>  static int config_parse_pair(const char *key, const char *value,
>  			  config_fn_t fn, void *data)
>  {
> @@ -1897,6 +1921,9 @@ static int do_git_config_sequence(const struct config_options *opts,
>  		repo_config = NULL;
>  
>  	current_parsing_scope = CONFIG_SCOPE_SYSTEM;
> +
> +	git_config_default(fn, data);
> +
>  	if (git_config_system() && system_config &&
>  	    !access_or_die(system_config, R_OK,
>  			   opts->system_gently ? ACCESS_EACCES_OK : 0))
> @@ -3497,6 +3524,8 @@ const char *current_config_origin_type(void)
>  		return "submodule-blob";
>  	case CONFIG_ORIGIN_CMDLINE:
>  		return "command line";
> +	case CONFIG_ORIGIN_DEFAULT:
> +		return "default";
>  	default:
>  		BUG("unknown config origin type");
>  	}

Ah, this is likely it, do we incclude this in 'git config -l' etc? 

> diff --git a/config.h b/config.h
> index 9038538ffd..bc3ecca313 100644
> --- a/config.h
> +++ b/config.h
> @@ -58,7 +58,8 @@ enum config_origin_type {
>  	CONFIG_ORIGIN_FILE,
>  	CONFIG_ORIGIN_STDIN,
>  	CONFIG_ORIGIN_SUBMODULE_BLOB,
> -	CONFIG_ORIGIN_CMDLINE
> +	CONFIG_ORIGIN_CMDLINE,
> +	CONFIG_ORIGIN_DEFAULT
>  };
>  
>  enum config_event_t {
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 49b80a4eb5..a15965e2f4 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -456,6 +456,8 @@ GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-sha1}"
>  export GIT_DEFAULT_HASH
>  GIT_TEST_MERGE_ALGORITHM="${GIT_TEST_MERGE_ALGORITHM:-ort}"
>  export GIT_TEST_MERGE_ALGORITHM
> +GIT_NO_DEFAULT_ALIASES=1
> +export GIT_NO_DEFAULT_ALIASES
>  
>  # Tests using GIT_TRACE typically don't want <timestamp> <file>:<line> output
>  GIT_TRACE_BARE=1

Really needs more tests.

We had some other thread where this was discussed where I suggested that
we implement some way to include default config. Ah, here it is:
https://lore.kernel.org/git/87eedj74dr.fsf@evledraar.gmail.com/

It's more work for this, but I think it would really go a long way to
addressing the concerns people are going to have about this.

I think we should not opt-in to this from day one, but have some knob to
enable including one of those shipped-by-default alias includes. Then
people could trivially mock svn/cvs or whatever their favorite VCS is,
and eventually as people vote with their feed we could pick a canonical
one.

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> 
> On Fri, Jul 02 2021, Felipe Contreras wrote:
> 
> > These are all the aliases everyone agrees are essential.
> >
> > Virtually all VCS in the world have aliases, except git, so let's change
> > that.
> >
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> >  Documentation/git-branch.txt      |  4 ++++
> >  Documentation/git-cherry-pick.txt |  4 ++++
> >  Documentation/git-commit.txt      |  4 ++++
> >  Documentation/git-mergetool.txt   |  4 ++++
> >  Documentation/git-rebase.txt      |  4 ++++
> >  Documentation/git-status.txt      |  4 ++++
> >  config.c                          | 29 +++++++++++++++++++++++++++++
> >  config.h                          |  3 ++-
> >  t/test-lib.sh                     |  2 ++
> >  9 files changed, 57 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> > index 94dc9a54f2..fbf5ebd27a 100644
> > --- a/Documentation/git-branch.txt
> > +++ b/Documentation/git-branch.txt
> > @@ -24,6 +24,10 @@ SYNOPSIS
> >  'git branch' (-d | -D) [-r] <branchname>...
> >  'git branch' --edit-description [<branchname>]
> >  
> > +ALIAS
> > +~~~~~
> > +'git br'
> 
> I think for these it would be good to explicitly mention the mnemonic, e.g.:
> 
> 'git br', git 'br'anch. It's pretty obvious in this case, but not all of
> them.

If we are on `man git-branch(1)`, `git help branch`, or
`git branch --help` I think it's pretty obvious what the alias is for.

Especially since it's right after the synopsis.

FTR all other SCM's specify the alias directly. Perhaps we could even do
'br' instead of 'git br'.

> This also addresses the '"ci" or "co"' discussion downthread
> somewhat, i.e. at least we'll see if we always pick the first two
> letters, or if it's somewhat arbitrary.

How? What would be the mnemonic for 'ci'?

> > +~~~~~
> > +'git pi'
> 
> I've got this this as 'git chrp' locally FWIW, I'd think this would make
> more sense if it was called 'git pick'.

Yeah, but we are aiming for two letters the only other good option is
'cp' which can be easily confused.

For a past discussion on this alias see [1].

> > +~~~~~
> > +'git co'
> 
> Not going to wade into the downhtread co/ci discussion, except to say
> that this is 'co'mmit, i.e. first two letters, like 'br'anch.

Yeap, so it's straightforward.

> >  'git mergetool' [--tool=<tool>] [-y | --[no-]prompt] [<file>...]
> >  
> > +ALIAS
> > +~~~~~
> > +'git mt'
> 
> Maybe it's just me, but I don't think I've ever used git-mergetool
> directly. I don't think it's worthy of squatting on such a short name.

Huh? How is a user supposed to jump from a merge failing to mergetool?
(or rebase, or cherr-pick)

> > +ALIAS
> > +~~~~~
> > +'git rb'
> 
> So 'r'e'b'ase, not 're'base.

I don't know if 're' makes more sense here.

> >  'git status' [<options>...] [--] [<pathspec>...]
> >  
> > +ALIAS
> > +~~~~~
> > +'git st'
> 
> FWIW I've got this aliased to 'git status --short', anyway, 'st'atus, so
> first two letters...

Me too. Actually --short --branch.

> > +static int git_config_default(config_fn_t fn, void *data)
> > +{
> > +	int ret = 0;
> > +	struct config_source source;
> > +
> > +	if (getenv("GIT_NO_DEFAULT_ALIASES"))
> > +		return 0;
> 
> Can't we just include this under GIT_TEST_DISALLOW_ABBREVIATED_OPTIONS?
> Maybe rename it to GIT_TEST_DISALLOW_ABBREVIATED now that the "OPTIONS"
> part is considered inaccurate.

Fine by me.

> > +	memset(&source, 0, sizeof(source));
> > +	source.prev = cf;
> > +	source.origin_type = CONFIG_ORIGIN_DEFAULT;
> > +	cf = &source;
> > +
> > +	ret += fn("alias.co", "commit", data);
> > +	ret += fn("alias.rb", "rebase", data);
> > +	ret += fn("alias.st", "status", data);
> > +	ret += fn("alias.br", "branch", data);
> > +	ret += fn("alias.pi", "cherry-pick", data);
> > +	ret += fn("alias.mt", "mergetool", data);
> 
> I haven't looked but does this also inject things into the configset
> API, or is it just going to be used by things that do
> git_config_mycommand and fall back on git_config_default?

I'm not sure what you mean. But it's basically as if you have them in
a config file.

Initially I used a diffent approach but the bash completion did not pick
them up. This is as close to a config file as possible.

> >  static int config_parse_pair(const char *key, const char *value,
> >  			  config_fn_t fn, void *data)
> >  {
> > @@ -1897,6 +1921,9 @@ static int do_git_config_sequence(const struct config_options *opts,
> >  		repo_config = NULL;
> >  
> >  	current_parsing_scope = CONFIG_SCOPE_SYSTEM;
> > +
> > +	git_config_default(fn, data);
> > +
> >  	if (git_config_system() && system_config &&
> >  	    !access_or_die(system_config, R_OK,
> >  			   opts->system_gently ? ACCESS_EACCES_OK : 0))
> > @@ -3497,6 +3524,8 @@ const char *current_config_origin_type(void)
> >  		return "submodule-blob";
> >  	case CONFIG_ORIGIN_CMDLINE:
> >  		return "command line";
> > +	case CONFIG_ORIGIN_DEFAULT:
> > +		return "default";
> >  	default:
> >  		BUG("unknown config origin type");
> >  	}
> 
> Ah, this is likely it, do we incclude this in 'git config -l' etc? 

Yes. Just like all other configurations.

> > diff --git a/config.h b/config.h
> > index 9038538ffd..bc3ecca313 100644
> > --- a/config.h
> > +++ b/config.h
> > @@ -58,7 +58,8 @@ enum config_origin_type {
> >  	CONFIG_ORIGIN_FILE,
> >  	CONFIG_ORIGIN_STDIN,
> >  	CONFIG_ORIGIN_SUBMODULE_BLOB,
> > -	CONFIG_ORIGIN_CMDLINE
> > +	CONFIG_ORIGIN_CMDLINE,
> > +	CONFIG_ORIGIN_DEFAULT
> >  };
> >  
> >  enum config_event_t {
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 49b80a4eb5..a15965e2f4 100644
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -456,6 +456,8 @@ GIT_DEFAULT_HASH="${GIT_TEST_DEFAULT_HASH:-sha1}"
> >  export GIT_DEFAULT_HASH
> >  GIT_TEST_MERGE_ALGORITHM="${GIT_TEST_MERGE_ALGORITHM:-ort}"
> >  export GIT_TEST_MERGE_ALGORITHM
> > +GIT_NO_DEFAULT_ALIASES=1
> > +export GIT_NO_DEFAULT_ALIASES
> >  
> >  # Tests using GIT_TRACE typically don't want <timestamp> <file>:<line> output
> >  GIT_TRACE_BARE=1
> 
> Really needs more tests.
> 
> We had some other thread where this was discussed where I suggested that
> we implement some way to include default config. Ah, here it is:
> https://lore.kernel.org/git/87eedj74dr.fsf@evledraar.gmail.com/
> 
> It's more work for this, but I think it would really go a long way to
> addressing the concerns people are going to have about this.
> 
> I think we should not opt-in to this from day one, but have some knob to
> enable including one of those shipped-by-default alias includes. Then
> people could trivially mock svn/cvs or whatever their favorite VCS is,
> and eventually as people vote with their feed we could pick a canonical
> one.

As I mentioned there the problem is where do we put that file, and how
do we distribute it.

I think it's a cleaner approach, and we should definitely try it, but
ultimately it's not going to change the fact that these aliases should
be part of the distribution, especially if they are mentioned in the man
pages. So it would just be an alternative way of hardcoding them.

[1] https://lore.kernel.org/git/20140421204506.GD5105@thunk.org/

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[martin]

On 02/07/2021 23:58, Felipe Contreras wrote:
> Ævar Arnfjörð Bjarmason wrote:
>>> +ALIAS
>>> +~~~~~
>>> +'git rb'
>> So 'r'e'b'ase, not 're'base.
> I don't know if 're' makes more sense here.

re:
restore
rebase
reset

And restore is on the level of checkout => so more important.

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

martin wrote:
> On 02/07/2021 23:58, Felipe Contreras wrote:
> > Ævar Arnfjörð Bjarmason wrote:
> >>> +ALIAS
> >>> +~~~~~
> >>> +'git rb'
> >> So 'r'e'b'ase, not 're'base.
> > I don't know if 're' makes more sense here.
> 
> re:
> restore
> rebase
> reset
> 
> And restore is on the level of checkout => so more important.

Right. Although we don't need to have aliases for all of them it's good
to be consistent, so perhaps:

  rb => rebase
  rs => reset
  rt => restore

I don't use restore (yet), but it's probably the one most people would
use most regularly, so maybe 're' instead of 'rt'.

-- 
Felipe Contreras

RE: [PATCH 5/5] config: add default aliases

[Randall S. Becker]

On July 2, 2021 6:38 PM, martin wrote:
>To: Felipe Contreras <felipe.contreras@gmail.com>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>Cc: git@vger.kernel.org; Junio C Hamano <gitster@pobox.com>
>Subject: Re: [PATCH 5/5] config: add default aliases
>
>On 02/07/2021 23:58, Felipe Contreras wrote:
>> Ævar Arnfjörð Bjarmason wrote:
>>>> +ALIAS
>>>> +~~~~~
>>>> +'git rb'
>>> So 'r'e'b'ase, not 're'base.
>> I don't know if 're' makes more sense here.
>
>re:
>restore
>rebase
>reset
>
>And restore is on the level of checkout => so more important.

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 topic branches for delivery. git 're' is certainly not helpful.

From 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:

include="/path/to/alias-config"

which 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.

RE: [PATCH 5/5] config: add default aliases

[Randall S. Becker]

On July 5, 2021 10:03 AM, I wrote:
>On July 2, 2021 6:38 PM, martin wrote:
>>To: Felipe Contreras <felipe.contreras@gmail.com>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>Cc: git@vger.kernel.org; Junio C Hamano <gitster@pobox.com>
>>Subject: Re: [PATCH 5/5] config: add default aliases
>>
>>On 02/07/2021 23:58, Felipe Contreras wrote:
>>> Ævar Arnfjörð Bjarmason wrote:
>>>>> +ALIAS
>>>>> +~~~~~
>>>>> +'git rb'
>>>> So 'r'e'b'ase, not 're'base.
>>> I don't know if 're' makes more sense here.
>>
>>re:
>>restore
>>rebase
>>reset
>>
>>And restore is on the level of checkout => so more important.
>
>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
>topic branches for delivery. git 're' is certainly not helpful.
>
>>From 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:
>
>include="/path/to/alias-config"
>
>which 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.

This is already in place in .gitconfig:

[include]
	path = /path/to/git-aliases

So 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.

-Randall

RE: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Randall S. Becker wrote:
> On July 2, 2021 6:38 PM, martin wrote:
> >To: Felipe Contreras <felipe.contreras@gmail.com>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> >Cc: git@vger.kernel.org; Junio C Hamano <gitster@pobox.com>
> >Subject: Re: [PATCH 5/5] config: add default aliases
> >
> >On 02/07/2021 23:58, Felipe Contreras wrote:
> >> Ævar Arnfjörð Bjarmason wrote:
> >>>> +ALIAS
> >>>> +~~~~~
> >>>> +'git rb'
> >>> So 'r'e'b'ase, not 're'base.
> >> I don't know if 're' makes more sense here.
> >
> >re:
> >restore
> >rebase
> >reset
> >
> >And restore is on the level of checkout => so more important.
> 
> I do not want anything helping out the use of rebase, which we actively discourage in our shop

That is a problem specific for your shop.

The defaults are meant for the majority of users. If a minority of users
(who happen to be working under the same umbrella) have a problem with
the defaults, they can change the defaults.

-- 
Felipe Contreras

Re: [PATCH 5/5] config: add default aliases

[Philip Oakley]

On 05/07/2021 15:02, Randall S. Becker wrote:
> 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.

I was wondering what the background/context to the 'actively discourage'
is? 

I'd have expected that some in-place rework (i.e. rebase) could happen
before code review, with possible further rework beyond simple
fixup/squash commits being possible after review (if demanded), but with
the same fork-point (rather than following movements in the 'upstream'),
rather similar to Git's development. i.e. Is it that the fork-point
shouldn't be moved without good reason and permission, or something else?

just wondering...

--
Philip

Re: [PATCH 5/5] config: add default aliases

[Jeff King]

On Fri, Jul 02, 2021 at 05:05:06AM -0500, Felipe Contreras wrote:

> These are all the aliases everyone agrees are essential.
> 
> Virtually all VCS in the world have aliases, except git, so let's change
> that.

For anyone reviewing or discussing, here's an older thread on the same
topic:

  https://lore.kernel.org/git/1379791221-29925-1-git-send-email-felipe.contreras@gmail.com/

(I don't mean to imply that we can't revisit old decisions; but some of
the thoughts there are worth considering as input).

-Peff

Re: [PATCH 5/5] config: add default aliases

[Felipe Contreras]

Jeff King wrote:
> On Fri, Jul 02, 2021 at 05:05:06AM -0500, Felipe Contreras wrote:
> 
> > These are all the aliases everyone agrees are essential.
> > 
> > Virtually all VCS in the world have aliases, except git, so let's change
> > that.
> 
> For anyone reviewing or discussing, here's an older thread on the same
> topic:
> 
>   https://lore.kernel.org/git/1379791221-29925-1-git-send-email-felipe.contreras@gmail.com/
> 
> (I don't mean to imply that we can't revisit old decisions; but some of
> the thoughts there are worth considering as input).

Re-reading that thread--and filtering all the noise--the two thoughts
that I think are worth considering are:

 1. A default alias might leak into some unofficial documentation, and
    people with a different alias could be surprised after typing that
    command and finding out it does a different thing.

 2. A person might be used to an alias doing one thing, move to a
    different machine, and be surprised that the default alias does a
    diffrent thing.

But as mentioned in that thread those two are *existing* issues. People
using certain configurations (not even aliases) are surprised when the
same command does a different thing. And also people use their aliases
in unofficial documentation already.

Default aliases would in fact make the situation less worse because if
one of these aliases leaks into unofficial documentation, there's a
higher chance that the command will do what was intended.

The counter-arguments were not addressed, so the conclussion is that
default aliases would *not* make the existing problems worse.


That being said, there's ways to mitigate these problems, for example we
could add an avdice stating that a default alias is currently being
used, something like:

  hint: You are using a default alias: co -> checkout.
  hint:
  hint: If you want to incorporate this alias into your personal
  hint: aliases, type:
  hint:
  hint:  git config --global alias.co checkout
  hint:
  hint: Disable this message with "git config advice.defaultaliases false"

There's many other ways to mitigate the issues. It would be in the best
inerest of the probject to explore all these possibilities to their full
extent instead of just throwing the towel and stay in the current
undesirable state.

Cheers.

-- 
Felipe Contreras