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/
next prev 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).