Re: The git spring cleanup challenge

> Ævar Arnfjörð Bjarmason wrote:
>> 
>> On Tue, Jun 01 2021, Felipe Contreras wrote:
>> 
>> > Đoàn Trần Công Danh wrote:
>> >> On 2021-06-01 05:48:41-0500, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> >> > > 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?
>> >
>> >> 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.
>> >
>> >> 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)
>> >
>> >
>> >> 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.
>
>> 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.