On 2021-06-01 05:48:41-0500, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > Đoàn Trần Công Danh wrote: > > On 2021-06-01 01:24:01-0500, Felipe Contreras <felipe.contreras@xxxxxxxxx> 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
