Re: The git spring cleanup challenge

On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:

Đoàn Trần Công Danh wrote:

quoted

On 2021-06-01 01:24:01-0500, Felipe Contreras [off-list ref] wrote:

quoted

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.

quoted

quoted

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.

OK.

quoted

quoted

  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.

I think both pull, merge, rebase, cherry-pick, revert, checkout,
switch, apply, am will be affected by rerere.

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

Dun know. I guess someone applies other people patches
with their rerere logs.

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?

quoted

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?

I don't use git-pull nowaday, so, I don't care.

quoted

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.

quoted

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.

Fair!

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

quoted

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.

The point of trying new shiny features is dogfooding ourselves and
report bugs early, if any.

quoted

quoted

  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

OK, let's start there.

-- 
Danh