From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 5/5] config: add default aliases
Date: Fri, 02 Jul 2021 13:32:48 +0200 [thread overview]
Message-ID: <8735sxaqln.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20210702100506.1422429-6-felipe.contreras@gmail.com>
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.
next prev parent reply other threads:[~2021-07-02 11:43 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 10:05 [PATCH 0/5] Default aliases Felipe Contreras
2021-07-02 10:05 ` [PATCH 1/5] test: add missing whitespaces Felipe Contreras
2021-07-02 10:05 ` [PATCH 2/5] config: trivial style fix Felipe Contreras
2021-07-02 10:05 ` [PATCH 3/5] config: trivial struct initialization cleanup Felipe Contreras
2021-07-02 10:05 ` [PATCH 4/5] config: initialize origin_type correctly Felipe Contreras
2021-07-02 10:05 ` [PATCH 5/5] config: add default aliases Felipe Contreras
2021-07-02 10:10 ` Andreas Schwab
2021-07-02 10:17 ` Felipe Contreras
2021-07-02 10:31 ` Andreas Schwab
2021-07-02 10:46 ` Felipe Contreras
2021-07-02 10:54 ` Andreas Schwab
2021-07-02 10:44 ` martin
2021-07-02 10:54 ` Felipe Contreras
2021-07-02 11:15 ` martin
2021-07-02 13:26 ` Randall S. Becker
2021-07-02 13:41 ` Ævar Arnfjörð Bjarmason
2021-07-02 14:15 ` Randall S. Becker
2021-07-02 14:43 ` martin
2021-07-02 20:44 ` Felipe Contreras
2021-07-02 22:03 ` Randall S. Becker
2021-07-02 22:32 ` Felipe Contreras
2021-07-02 15:39 ` Junio C Hamano
2021-07-02 20:41 ` Felipe Contreras
2021-07-02 21:02 ` Felipe Contreras
2021-07-02 21:40 ` martin
2021-07-02 22:16 ` Felipe Contreras
2021-07-02 22:00 ` Randall S. Becker
2021-07-02 22:31 ` Felipe Contreras
2021-07-02 21:12 ` Felipe Contreras
2021-07-02 21:31 ` martin
2021-07-02 22:14 ` Felipe Contreras
2021-07-02 11:32 ` Ævar Arnfjörð Bjarmason [this message]
2021-07-02 21:58 ` Felipe Contreras
2021-07-02 22:38 ` martin
2021-07-02 23:48 ` Felipe Contreras
2021-07-05 14:02 ` Randall S. Becker
2021-07-06 15:27 ` Randall S. Becker
2021-07-06 21:59 ` Felipe Contreras
2021-07-10 15:30 ` Philip Oakley
2021-07-03 10:50 ` Jeff King
2021-07-06 21:54 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735sxaqln.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).