git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: "Đoàn Trần Công Danh" <congdanhqx@gmail.com>,
	"Felipe Contreras" <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: The git spring cleanup challenge
Date: Tue, 01 Jun 2021 05:48:41 -0500	[thread overview]
Message-ID: <60b61089ba63d_e40ca20894@natae.notmuch> (raw)
In-Reply-To: <YLXl5+ronWhcGh13@danh.dev>

Đoàn Trần Công Danh wrote:
> On 2021-06-01 01:24:01-0500, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > The premise is simple: git.git developers are experts in git, and therefore
> > they have fine-tuned their ~/.gitconfig to a point that is pretty far
> > from what any newcomer will experience for a long time.
> > 
> > How long can you survive with a pristine configuration?
> > 
> > Plenty of developers take many things in their configuration for
> > granted, they forget what the default behavior is, or worse: they forget
> > they actually have configured log.decorate, and are surprised when they
> > discover the reason they could not reproduce a bug report.
> 
> OK, the person that forgot having log.decorate configured is me.

Right. That's just the most recent instance I could think of, but I'm
sure similar versions have happened to all of us.

> > Now and then I cleanup my configuration to be reminded of that fact.
> > 
> > Anybody remembers merge.defaultToUpstream, and what `git merge` without
> > arguments used to do? [1] What about sendemail.chainReplyTo? [2]
> > 
> > It's important that we force ourselves to experience what an
> > unconfigured git setup looks like, even if it's just for a little bit.
> > 
> > So the challenge is this:
> > 
> >   1. Remove all the configuration that is not essential (just leave
> >      user.name and user.email or equivalent)
> 
> 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.

> >   2. Pick 2 configurations you think you can't live without. You are not
> >      allowed to change them afterwards.
> 
> Something is essential when working on constantly integration tree,
> I don't want to make my life hard:
> 
> * rerere.enabled = true
> * rerere.autoupdate = true

If the defaults make your life hard, then shouldn't we change the
defaults?

For starters, which is the command you use? `git merge`? If so, maybe
`git merge` should have a --rerere option to enable rerere. There are
some --rerere-autoupdate, but no --rerere.

Additionally, who doesn't want autoupdate when rerere is manually
enabled?

If we all want autoupdate enabled (at least I do), maybe the default
should be flipped, so all you need in your configuration is:

  rerere.enabled = true

But, if we are already on this topic... who wants rerere disabled by
default?

> Something is there to shut up advice, I can live without those
> configuration value, though (I don't use git-pull these days, anyway):
> 
> * pull.rebase = false

Can you train your fingers to type `git pull --no-rebase` for a while?

> Working with patch based need:
> 
> * sendemail.smtpserver
> * sendemail.smtpencryption
> * sendemail.smtpuser
> * credential.helper

You could use msmtp instead, but fine, let's make an exception for
transmission of patches (credentials, SMTP, etc.) These are not options
that can be changed in git.gt by default.

But only the essentials, no sendemail.confirm.

> My GnuPG key is Ed25519, and gpg v2 in my machine is named gpg2, so:
> * gpg.program = gpg2

You could have an alias in your ~/bin directory:

  ln -s /usr/bin/gpg2 ~/bin/gpg

That way you don't need to configure every program.

But fine, this is an exception too. The location of programs is not
something that can be changed by default.

> And I would like to try new shiny features:
> 
> * feature.experimental = true

Interesting. I didn't know that existed, and I advocated for a
similar configuration: core.mode [2].

But if most newcomers can live without it, I'm sure you can too for a
bit.

> >   3. Every day you can add 1 additional configuration (and update it the
> >      next day).
> >   4. The moment you add a 4th configuration you lose.
> 
> So, my baseline already requires 8 key-value pairs (ignoring alias and
> pull.rebase). I'm lost already.

With the exceptions I think you only need these:

 * rerere.enabled = true
 * rerere.autoupdate = true


But the point is that if you can't live with git defaults, that should
tell us something.

Cheers.

[1] https://lore.kernel.org/git/1379791221-29925-1-git-send-email-felipe.contreras@gmail.com/
[2] https://lore.kernel.org/git/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com/

-- 
Felipe Contreras

  reply	other threads:[~2021-06-01 10:48 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 [this message]
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
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=60b61089ba63d_e40ca20894@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=congdanhqx@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).