Re: The git spring cleanup challenge
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-06-03 08:14:19
On Tue, Jun 01 2021, Felipe Contreras wrote:
quoted hunk ↗ jump to hunk
Đoàn Trần Công Danh wrote:quoted
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:quoted
quoted
How about alias? It's part of my muscle memory.No aliases. If a new user doesn't have them, neither should you. All VCSs have default aliases, and I advocated for git to do the same [1], but it wasn't accepted. The whole point is to suffer like them.Get back to the alias topic. I also agree with other people's opinion in that thread. IOW, I support the decision to not accept those default alias ;)Why?quoted
It's not required to be different people to have alias defined to different command. I have alias conditionally defined to different command based on git-dir. For example, I had ci alias to "commit" by default, and "commit -s" on other repositories.So? They would still work.quoted
So, Git decides alias for me will not only break my current alias, but also break my conditional alias.No it wouldn't. They are *default* aliases, not overriding aliases. They would be used only if you haven't set the same alias yourself. Try it.--- a/alias.c +++ b/alias.c@@ -28,13 +28,27 @@ static int config_alias_cb(const char *key, const char *value, void *d) return 0; } +struct config_alias_data default_aliases[] = { + { "co", "checkout" }, + { "ci", "checkout" }, + { "rb", "rebase" }, + { "st", "status" }, +}; + char *alias_lookup(const char *alias) { struct config_alias_data data = { alias, NULL }; + int i; read_early_config(config_alias_cb, &data); + if (data.v) + return data.v; + for (i = 0; i < ARRAY_SIZE(default_aliases); i++) { + if (!strcmp(alias, default_aliases[i].alias)) + return xstrdup(default_aliases[i].v); + } - return data.v; + return NULL; } void list_aliases(struct string_list *list)quoted
Anyway, remotes/branches are all configuration values. Would you prefer:I meant global configurations. If it's a per-repository setting surely it wouldn't be something amenable for the Git project to set as default.
I agree with this batteries included sentiment, but would very much like to not see this as hardcoding of ours, but us shipping optional config files to be included. We could then just extend the include syntax rather easily to include "libraries", which would be like the current include.path, but would understand a library:: prefix (better name bikeshedding welcome). We'd then just ship these in /usr/share/git-core/config/includes or whatever, e.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg Part of that goes against what I was arguing for in [1], but I suppose if that's a problem we could always optionally compile these in (in Go-like fashion), while retaining the semantics. The advantage of doing that is that you don't have to bless one set of aliases, e.g. you could have cvs-like.cfg, svn-like.cfg etc. 1. https://lore.kernel.org/git/87czvoowg2.fsf@evledraar.gmail.com/ (local)