git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: "Đoàn Trần Công Danh" <congdanhqx@gmail.com>, git@vger.kernel.org
Subject: Re: The git spring cleanup challenge
Date: Thu, 03 Jun 2021 14:18:15 +0200	[thread overview]
Message-ID: <87zgw75dyi.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <60b8a98d11d7c_1a0a2d20856@natae.notmuch>


On Thu, Jun 03 2021, Felipe Contreras wrote:

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

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/

  parent reply	other threads:[~2021-06-03 12:30 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-01  6:24 The git spring cleanup challenge Felipe Contreras
2021-06-01  7:28 ` Andy
2021-06-01 10:07   ` Felipe Contreras
2021-06-01  7:47 ` Đoàn Trần Công Danh
2021-06-01 10:48   ` Felipe Contreras
2021-06-01 11:40     ` Đoàn Trần Công Danh
2021-06-01 12:21       ` Felipe Contreras
2021-06-01 12:28         ` Đoàn Trần Công Danh
2021-06-01 13:14           ` Felipe Contreras
2021-06-02  4:13     ` Đoàn Trần Công Danh
2021-06-02  4:53       ` Felipe Contreras
2021-06-03  8:03         ` Ævar Arnfjörð Bjarmason
2021-06-03 10:06           ` Felipe Contreras
2021-06-03 10:49             ` Sergey Organov
2021-06-03 12:18             ` Ævar Arnfjörð Bjarmason [this message]
2021-07-02 10:12               ` Felipe Contreras
2021-07-02 11:43                 ` Ævar Arnfjörð Bjarmason
2021-07-02 21:54                   ` Felipe Contreras
2021-06-01 21:56 ` David Aguilar
2021-06-01 22:28   ` Junio C Hamano
2021-06-01 22:49     ` Junio C Hamano
2021-06-01 23:44       ` Felipe Contreras
2021-06-02  6:47         ` Johannes Sixt
2021-06-02  6:53           ` Felipe Contreras
2021-06-02 11:00           ` Junio C Hamano
2021-06-02 11:24             ` Felipe Contreras
2021-06-02 11:44             ` Đoàn Trần Công Danh
2021-06-02 18:13               ` Johannes Sixt
2021-06-01 23:12     ` Felipe Contreras
2021-06-02 12:13       ` Sergey Organov
2021-06-03  3:00         ` Junio C Hamano
2021-06-03 10:00           ` Sergey Organov
2021-06-01 22:33 ` Sergey Organov
2021-06-01 23:19   ` Felipe Contreras
2021-06-02 12:19     ` Sergey Organov
2021-06-02 21:28       ` Felipe Contreras
2021-06-02 22:05         ` Sergey Organov
2021-06-02 22:33           ` Felipe Contreras
2021-06-02 23:09             ` Sergey Organov
2021-06-03  0:06       ` Junio C Hamano
2021-06-03  0:48         ` Felipe Contreras
2021-06-03  0:26   ` Elijah Newren
2021-06-03  1:36     ` Felipe Contreras
2021-06-03  4:25       ` Elijah Newren
2021-06-03  9:52         ` Felipe Contreras
2021-06-03  9:48     ` Sergey Organov
2021-06-02  3:43 ` Bagas Sanjaya
2021-06-02  3:59   ` Felipe Contreras
2021-06-03  8:15 ` Ævar Arnfjörð Bjarmason
2021-06-03 11:09   ` Felipe Contreras
2021-06-03 12:31     ` Ævar Arnfjörð Bjarmason
2021-06-03 14:28       ` Phillip Wood
2021-06-03 16:44         ` Ævar Arnfjörð Bjarmason
2021-06-04 10:24           ` Phillip Wood
2021-06-03 17:28       ` 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=87zgw75dyi.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    /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).