Re: The git spring cleanup challenge

On Thu, Jun 03 2021, Felipe Contreras wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

On Tue, Jun 01 2021, Felipe Contreras wrote:

quoted

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

The problem with optional config files is that you can't standardize
that way.

If hard-coded default aliases they can be included in the documentation.

Pluse we all start to typing similar commands, instead of each having
completely different alias to the next.

For example in 3 days of doing this experiment I've typed 'g c'
countless of times (alias for `commit -v`). I added an alias for `ci`
instead, since that what other VCSs use, like Mercurial. But I don't
think `ci` makes sense for commit. It would be better if `co` was
available, but then checkout needs another alias.

If we could replace checkout with switch, then we could have an alias
`sw` for switch, and another `co` for commit.

But that requires that switch is actually usable (it isn't for me right
now).

This increases the urgency to fix `git switch` for me. If other
developers were trying the same aliases they might see the same issues.

quoted

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

I wouldn't be against some some suggested defaults, but *in addition* to
some hardcoded default aliases that are documented.

I'm talking about in terms of the flexibility of implementation of
on-by-default defaults. We could implement it as I suggested and then
just have a core.defaultIncludes, which would by default be set to
git::aliases/svn-like.cfg or whatever, i.e. equivalent to:

    [core]
    defaultIncludes = "git::default.cfg"

Which itself would include a
/usr/share/git-core/config/includes/default.cfg which would do:

    [include]
    path = "git::aliases/svn-like.cfg"
    paht = <some other default file>

So it would work out of the box on a vanilla git install, you could then
in ~/.gitconfig or whatever set:

    [core]
    defaultIncludes = false

Or whatever, which we'd check for early with repo_config_get_bool() (see
repo-settings.c).

So you'd have an out from these optional vanilla includes. Then to
address the concern in [1] we could (sans the user-diff specific
limitations in that thread) treat the default userdiff "config" this way
and (optionally) slurp these up into a generated *.c file at build-time.

In a way this is total bikeshedding, I just think it's worth doing it
this way up-front.

It gives you a lot more flexibility than hardcoding these in the source
somewhere. It becomes easy e.g. to have multiple "default" variants, so
feature.experimental or whatever could give you early opt-in to new
aliases, or the other way around of new versions maintaining
compatibility with older style invocations via aliases.

1. https://lore.kernel.org/git/87czvoowg2.fsf@evledraar.gmail.com/ (local)