Re: The git spring cleanup challenge

["Đoàn Trần Công Danh" <congdanhqx@gmail.com>]

On 2021-06-01 05:48:41-0500, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> Đ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.

OK.

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

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

Fair!

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

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

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