The git spring cleanup challenge

The git spring cleanup challenge

[Felipe Contreras]

Hello,

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.

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)
  2. Pick 2 configurations you think you can't live without. You are not
     allowed to change them afterwards.
  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.

Once you've lost, reply to this message with the configuration you could
not live without.

These are the configurations I've chosen:

  [merge]
    conflictstyle = diff3
  [sendemail]
    smtpserver = /usr/bin/msmtp

If if not clear yet, I hope by the end of this little experiment we will
have at least one configuration that surely everyone can agree needs to
become a default.

Do you think you can survive one month?

Good luck!

[1] https://lore.kernel.org/git/1296231457-18780-1-git-send-email-felipe.contreras@gmail.com/
[2] https://lore.kernel.org/git/1369453492-20972-1-git-send-email-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Andy]

I'm not a git developer, as I see it written on the community related page.

 > General questions or comments for the Git community can be sent to 
the mailing list by using the email address git@vger.kernel.org .

My understanding is that even if it's not an advanced question about the 
details of development, but just a general question, it's still possible 
to discuss it on this mailing list.

At the moment my configuration file is quite short, but you mentioned 
that the configuration files of the masters are often very long, which 
reminds me that there is a lot of room for optimization.

Getting out of your comfort zone is not even an easy task, and 
understanding the problem clearly does require preventing expert bias, 
which is not easy.

Re: The git spring cleanup challenge

[Đoàn Trần Công Danh]

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

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

>   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

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

Working with patch based need:

* sendemail.smtpserver
* sendemail.smtpencryption
* sendemail.smtpuser
* credential.helper

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

And I would like to try new shiny features:

* feature.experimental = true

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

-- 
Danh

Re: The git spring cleanup challenge

[Felipe Contreras]

Andy wrote:
> My understanding is that even if it's not an advanced question about the 
> details of development, but just a general question, it's still possible 
> to discuss it on this mailing list.

Yes it is.

> At the moment my configuration file is quite short, but you mentioned 
> that the configuration files of the masters are often very long, which 
> reminds me that there is a lot of room for optimization.

Indeed. But efen if it's short, do you need more than 2 configurations?
(other than user.{name,email})? If so, maybe you could participate too,
and let us know which you couldn't live without.

> Getting out of your comfort zone is not even an easy task, and 
> understanding the problem clearly does require preventing expert bias, 
> which is not easy.

Exactly. And getting rid of our precious ~/.gitconfig (even if it's just
for a while) is a straightforward way to force us out.

Cheers.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Felipe Contreras]

Đ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

Re: The git spring cleanup challenge

[Đoàn Trần Công Danh]

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

Re: The git spring cleanup challenge

[Felipe Contreras]

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

Yes, I know, but I am talking about you personally. Where do you
absolutely need --rerere?

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

Yes, and more developers should turn this flag on, but it's not
*essential*, so you can live one month with it off. Either way I don't
think it matters for the purpose of this experiment if you have it or
not.

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

Excellent.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Đoàn Trần Công Danh]

On 2021-06-01 07:21:57-0500, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> Đoàn Trần Công Danh wrote:
> > On 2021-06-01 05:48:41-0500, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > > Đoàn Trần Công Danh wrote:
> > > > 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.
> 
> Yes, I know, but I am talking about you personally. Where do you
> absolutely need --rerere?

I need rerere in both of merge, rebase, cherry-pick, revert, switch, am
Don't ask me why, I use all of them in a daily basis. And rerere saves
me a lot of trouble.

I don't use git-pull nowaday. But, should I use git-pull,
I'll need rerere there, too (it's a fetch followed by merge/rebase,
anyway).

-- Danh

> > > 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.
> 
> Yes, and more developers should turn this flag on, but it's not
> *essential*, so you can live one month with it off. Either way I don't
> think it matters for the purpose of this experiment if you have it or
> not.
> 
> > > > >   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.
> 
> Excellent.
> 
> -- 
> Felipe Contreras

-- 
Danh

Re: The git spring cleanup challenge

[Felipe Contreras]

Đoàn Trần Công Danh wrote:
> On 2021-06-01 07:21:57-0500, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > Yes, I know, but I am talking about you personally. Where do you
> > absolutely need --rerere?
> 
> I need rerere in both of merge, rebase, cherry-pick, revert, switch, am
> Don't ask me why, I use all of them in a daily basis. And rerere saves
> me a lot of trouble.

Fair enough. If you need it you need it.

But probably many users would benefit from rerere too, and they don't
even realize it exists.

BTW. I've done integrations too, and I understand perfectly why you need
it.

Cheers.

https://github.com/felipec/git-reintegrate

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[David Aguilar]

On Mon, May 31, 2021 at 11:26 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> So the challenge is this:
>
>   1. Remove all the configuration that is not essential (just leave
>      user.name and user.email or equivalent)
>   2. Pick 2 configurations you think you can't live without. You are not
>      allowed to change them afterwards.
>   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.
>
> Once you've lost, reply to this message with the configuration you could
> not live without.

+1 for merge.conflictstyle = diff3, rerere.enabled = true, and
log.decorate = short from me. I noticed others already mentioned
these.

My favorites which no one has mentioned yet are rebase.autosquash =
true and rebase.autostash = true. IMO these two really improve
rebase's usability.

cheers,
-- 
David

Re: The git spring cleanup challenge

[Junio C Hamano]

David Aguilar <davvid@gmail.com> writes:

> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and
> log.decorate = short from me. I noticed others already mentioned
> these.

As the inventor of rerere, I agree on rerere.enabled.  It was made
opt-in only because I thought it was somewhat risky when the feature
was introduced, but it has been stable and useful, and it is long
overdue to be enabled by default.

I do not think of any downside with conflictstyle being diff3 (and
think of only upside).  As to log.decorate, I see it as mostly
personal preference and the current default of "auto" seems more
appropriate.

Re: The git spring cleanup challenge

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Hello,
>

[...]

> These are the configurations I've chosen:
>
>   [merge]
>     conflictstyle = diff3
>   [sendemail]
>     smtpserver = /usr/bin/msmtp
>

[pull]
	rebase = merges
[push]
	default = simple
[rerere]
	enabled = true
	autoupdate = true
[diff]
	algorithm = patience
[merge]
        conflictStyle = diff3

-- Sergey Organov

Re: The git spring cleanup challenge

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> David Aguilar <davvid@gmail.com> writes:
>
>> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and
>> log.decorate = short from me. I noticed others already mentioned
>> these.
>
> As the inventor of rerere, I agree on rerere.enabled.  It was made
> opt-in only because I thought it was somewhat risky when the feature
> was introduced, but it has been stable and useful, and it is long
> overdue to be enabled by default.

Just to make sure, rerere.enabled is fine, but as I am not
comfortable to recommend rerere.autoupdate to any human users, I
would be opposed to turning it on by default.  Giving people a
choice is fine, but the default should be a safe one that offers
users a chance of final sanity checking before proceeding.

Re: The git spring cleanup challenge

[Felipe Contreras]

Junio C Hamano wrote:
> David Aguilar <davvid@gmail.com> writes:
> 
> > +1 for merge.conflictstyle = diff3, rerere.enabled = true, and
> > log.decorate = short from me. I noticed others already mentioned
> > these.
> 
> As the inventor of rerere, I agree on rerere.enabled.  It was made
> opt-in only because I thought it was somewhat risky when the feature
> was introduced, but it has been stable and useful, and it is long
> overdue to be enabled by default.

Agreed.

I personally would like some interface to see what's going on behind the
scenes because sometimes I've made a wrong resolution that gets carried
around and I don't know of a way to clear them (other than manually
hunting down the cached files).

But this is not a deal-breaker, the feature works great.

> I do not think of any downside with conflictstyle being diff3 (and
> think of only upside).

Same here.

I recall reading about issues of a GSoC student resolving conflicts and
setting up a mergetool. And he (or she?) mentioned the advice to
configure diff3... I didn't even remember there was anything else.

I wrote vimdiff3 precisely to edit diff3 output directly, and I've never
looked back.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Felipe Contreras]

Sergey Organov wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:

> > These are the configurations I've chosen:
> >
> >   [merge]
> >     conflictstyle = diff3
> >   [sendemail]
> >     smtpserver = /usr/bin/msmtp
> >
> 
> [pull]
> 	rebase = merges

Can you do `git pull --rebase=merges` for a while?

> [push]
> 	default = simple

This is the default, you don't need it.

> [rerere]
> 	enabled = true
> 	autoupdate = true

We are seeing a pattern here.

> [diff]
> 	algorithm = patience

Does this make a lot of difference?

> [merge]
>         conflictStyle = diff3

Same here.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Felipe Contreras]

Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > David Aguilar <davvid@gmail.com> writes:

> >> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and
> >> log.decorate = short from me. I noticed others already mentioned
> >> these.
> >
> > As the inventor of rerere, I agree on rerere.enabled.  It was made
> > opt-in only because I thought it was somewhat risky when the feature
> > was introduced, but it has been stable and useful, and it is long
> > overdue to be enabled by default.
> 
> Just to make sure, rerere.enabled is fine, but as I am not
> comfortable to recommend rerere.autoupdate to any human users, I
> would be opposed to turning it on by default.  Giving people a
> choice is fine, but the default should be a safe one that offers
> users a chance of final sanity checking before proceeding.

No commit is made. Doesn't `git diff --staged` offer users such chance?

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Bagas Sanjaya]

Hi Felipe, sorry for responding in long time.

On 01/06/21 13.24, Felipe Contreras wrote:
> Once you've lost, reply to this message with the configuration you could
> not live without.
> 

I'm not opting in into the challenge, but here are my mandatory global 
configurations:

> [core]
>         editor = rvim

I set core.editor to rvim because of my habit to edit using restricted 
vim (as I only use vim to edit files, nothing else).

> [merge]
>         conflictstyle = diff3

With diff3 conflict style, I can clearly see the context of conflict 
(base) instead of having to choose between either side without context.

For several repos, I do GPG-sign commits, so the required config is:

> [user]
>         signingkey = <key>

On very large repos I have (for example GCC and Linux kernel), I have:

> [pack]
>         packSizeLimit = 650m
>         windowMemory = 400m

Both pack.packSizeLimit and pack.windowMemory helps when doing 
git-repack there. With the former, the resulting pack file is limited to 
650M size each, and the latter set memory window during delta compression.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

Re: The git spring cleanup challenge

[Felipe Contreras]

Bagas Sanjaya wrote:
> On 01/06/21 13.24, Felipe Contreras wrote:
> > Once you've lost, reply to this message with the configuration you could
> > not live without.
> > 
> 
> I'm not opting in into the challenge, but here are my mandatory global 
> configurations:
> 
> > [core]
> >         editor = rvim
> 
> I set core.editor to rvim because of my habit to edit using restricted 
> vim (as I only use vim to edit files, nothing else).

Why not VISUAL=rvim? (or EDITOR)

> > [merge]
> >         conflictstyle = diff3
> 
> With diff3 conflict style, I can clearly see the context of conflict 
> (base) instead of having to choose between either side without context.
> 
> For several repos, I do GPG-sign commits, so the required config is:

Yeap, just like apparently everyone else.

> On very large repos I have (for example GCC and Linux kernel), I have:
> 
> > [pack]
> >         packSizeLimit = 650m
> >         windowMemory = 400m
> 
> Both pack.packSizeLimit and pack.windowMemory helps when doing 
> git-repack there. With the former, the resulting pack file is limited to 
> 650M size each, and the latter set memory window during delta compression.

All right. But I presume you don't need to do `git repack` that often.
You can wait a month, or type --max-pack-size --window-memory if you
really must run it.

Either way it's probably not some defaults that newcomers would benefit
from.

Cheers.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Đoàn Trần Công Danh]

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

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, Git decides alias for me will not only break my current alias, but
also break my conditional alias.

Anyway, remotes/branches are all configuration values.
Would you prefer:

	git remote add a-remote git://some/repository.git
	git fetch a-remote a-branch && git merge FETCH_HEAD

or
	git fetch git://some/repository.git a-branch && git merge FETCH_HEAD

I guess it's another exception, then ;)

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

-- 
Danh

Re: The git spring cleanup challenge

[Felipe Contreras]

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

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Johannes Sixt]

Am 02.06.21 um 01:44 schrieb Felipe Contreras:
> Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> David Aguilar <davvid@gmail.com> writes:
> 
>>>> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and
>>>> log.decorate = short from me. I noticed others already mentioned
>>>> these.

Does diff3 conflict style reduce conflicts to their minimum? I don't
think so. Therefore, a strong -1 for this as the default.

>>> As the inventor of rerere, I agree on rerere.enabled.  It was made
>>> opt-in only because I thought it was somewhat risky when the feature
>>> was introduced, but it has been stable and useful, and it is long
>>> overdue to be enabled by default.
>>
>> Just to make sure, rerere.enabled is fine, but as I am not
>> comfortable to recommend rerere.autoupdate to any human users, I
>> would be opposed to turning it on by default.  Giving people a
>> choice is fine, but the default should be a safe one that offers
>> users a chance of final sanity checking before proceeding.
> 
> No commit is made. Doesn't `git diff --staged` offer users such chance?

rerere.autoupdate erases the information which files had conflicts. In
my workflow, the rerere database time and again does hold outdated merge
resolutions. I want to have an opportunity to cross-check the automatic
resolutions, and for that I need to know which files had conflicts.

I'm using a toolset on top of Git and am not paying attention to the
terminal---if and when I'm using it at all---that would list the
conflicted files. So, I'm strongly opposed to enabling it by default.

BTW, a +1 for rerere.enabled=true from me.

-- Hannes

Re: The git spring cleanup challenge

[Felipe Contreras]

Johannes Sixt wrote:
> Am 02.06.21 um 01:44 schrieb Felipe Contreras:
> > Junio C Hamano wrote:
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>> David Aguilar <davvid@gmail.com> writes:
> > 
> >>>> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and
> >>>> log.decorate = short from me. I noticed others already mentioned
> >>>> these.
> 
> Does diff3 conflict style reduce conflicts to their minimum?

The objective is to resolve conflicts, not to see minimum conflicts.

> >>> As the inventor of rerere, I agree on rerere.enabled.  It was made
> >>> opt-in only because I thought it was somewhat risky when the feature
> >>> was introduced, but it has been stable and useful, and it is long
> >>> overdue to be enabled by default.
> >>
> >> Just to make sure, rerere.enabled is fine, but as I am not
> >> comfortable to recommend rerere.autoupdate to any human users, I
> >> would be opposed to turning it on by default.  Giving people a
> >> choice is fine, but the default should be a safe one that offers
> >> users a chance of final sanity checking before proceeding.
> > 
> > No commit is made. Doesn't `git diff --staged` offer users such chance?
> 
> rerere.autoupdate erases the information which files had conflicts. In
> my workflow, the rerere database time and again does hold outdated merge
> resolutions. I want to have an opportunity to cross-check the automatic
> resolutions, and for that I need to know which files had conflicts.

Then do rerere.autoupdate=false.

Defaults are not for you, they are for the majority of users.

Cheers.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> rerere.autoupdate erases the information which files had conflicts.
> ... So, I'm strongly opposed to enabling it by default.

Exactly.  "checkout -m" can use resolve-undo information to
unresolve the conflicts, but to make effective use of it, you'd want
to know which paths had conflicts to begin with.

Re: The git spring cleanup challenge

[Felipe Contreras]

Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> 
> > rerere.autoupdate erases the information which files had conflicts.
> > ... So, I'm strongly opposed to enabling it by default.
> 
> Exactly.  "checkout -m" can use resolve-undo information to
> unresolve the conflicts, but to make effective use of it, you'd want
> to know which paths had conflicts to begin with.

Who is "you" in this case?

Is it the typical git user?

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Đoàn Trần Công Danh]

On 2021-06-02 20:00:25+0900, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> 
> > rerere.autoupdate erases the information which files had conflicts.
> > ... So, I'm strongly opposed to enabling it by default.
> 
> Exactly.  "checkout -m" can use resolve-undo information to
> unresolve the conflicts, but to make effective use of it, you'd want
> to know which paths had conflicts to begin with.

I don't know about this one. I had been bitten by rerere.autoupdate
sometimes. And I need to wipe out the rerere record to start over.

I guess I should turn it off, then.

-- 
Danh

Re: The git spring cleanup challenge

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Junio C Hamano wrote:
>> David Aguilar <davvid@gmail.com> writes:
>> 
>> > +1 for merge.conflictstyle = diff3, rerere.enabled = true, and
>> > log.decorate = short from me. I noticed others already mentioned
>> > these.
>> 
>> As the inventor of rerere, I agree on rerere.enabled.  It was made
>> opt-in only because I thought it was somewhat risky when the feature
>> was introduced, but it has been stable and useful, and it is long
>> overdue to be enabled by default.
>
> Agreed.
>
> I personally would like some interface to see what's going on behind the
> scenes because sometimes I've made a wrong resolution that gets carried
> around and I don't know of a way to clear them (other than manually
> hunting down the cached files).

I'm second here. Wanted to get rid of some recorded resolutions, but
didn't find a suitable way to.

Thanks,
-- Sergey Organov.

Re: The git spring cleanup challenge

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Sergey Organov wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> > These are the configurations I've chosen:
>> >
>> >   [merge]
>> >     conflictstyle = diff3
>> >   [sendemail]
>> >     smtpserver = /usr/bin/msmtp
>> >
>> 
>> [pull]
>> 	rebase = merges
>
> Can you do `git pull --rebase=merges` for a while?

I never use 'git pull' for merging, and all the time with rebasing, so
what's the point? I mean, whenever I do 'git pull' I mean 'git pull
--rebase', and whenever I need to merge, I exclusively use'git merge'.

>
>> [push]
>> 	default = simple
>
> This is the default, you don't need it.

Yep, a remnant from the past.

>
>> [rerere]
>> 	enabled = true
>> 	autoupdate = true
>
> We are seeing a pattern here.
>
>> [diff]
>> 	algorithm = patience
>
> Does this make a lot of difference?

As far as I recall, I had some mismerges long time ago that this setting
affected positively, so I've tweaked it.

Thanks,
-- Sergey Organov

Re: The git spring cleanup challenge

[Johannes Sixt]

Am 02.06.21 um 13:44 schrieb Đoàn Trần Công Danh:
> On 2021-06-02 20:00:25+0900, Junio C Hamano <gitster@pobox.com> wrote:
>> Johannes Sixt <j6t@kdbg.org> writes:
>>
>>> rerere.autoupdate erases the information which files had conflicts.
>>> ... So, I'm strongly opposed to enabling it by default.
>>
>> Exactly.  "checkout -m" can use resolve-undo information to
>> unresolve the conflicts, but to make effective use of it, you'd want
>> to know which paths had conflicts to begin with.
> 
> I don't know about this one. I had been bitten by rerere.autoupdate
> sometimes. And I need to wipe out the rerere record to start over.
> 
> I guess I should turn it off, then.

You can use

   git rerere forget that/file

to erase the record for the current resolution of that/file. Then you
can recreate the conflict using

   git checkout -m -- that/file

It may be necessary to run

   git rerere

at this point to save the pre-image of the conflict record, but I'm not
sure.

-- Hannes

Re: The git spring cleanup challenge

[Felipe Contreras]

Sergey Organov wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Sergey Organov wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >
> >> > These are the configurations I've chosen:
> >> >
> >> >   [merge]
> >> >     conflictstyle = diff3
> >> >   [sendemail]
> >> >     smtpserver = /usr/bin/msmtp
> >> >
> >> 
> >> [pull]
> >> 	rebase = merges
> >
> > Can you do `git pull --rebase=merges` for a while?
> 
> I never use 'git pull' for merging, and all the time with rebasing, so
> what's the point? I mean, whenever I do 'git pull' I mean 'git pull
> --rebase', and whenever I need to merge, I exclusively use'git merge'.

So you can remove that configuration.

And afterwareds set pull.rebase=true so you don't need to specify
--rebase.

> >> [rerere]
> >> 	enabled = true
> >> 	autoupdate = true
> >
> > We are seeing a pattern here.
> >
> >> [diff]
> >> 	algorithm = patience
> >
> > Does this make a lot of difference?
> 
> As far as I recall, I had some mismerges long time ago that this setting
> affected positively, so I've tweaked it.

Try running without it for a while. If you see issues then parhaps it's
an indication that patience is a better default algorithm.

Cheers.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Sergey Organov wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 
>> > Sergey Organov wrote:
>> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> >
>> >> > These are the configurations I've chosen:
>> >> >
>> >> >   [merge]
>> >> >     conflictstyle = diff3
>> >> >   [sendemail]
>> >> >     smtpserver = /usr/bin/msmtp
>> >> >
>> >> 
>> >> [pull]
>> >> 	rebase = merges
>> >
>> > Can you do `git pull --rebase=merges` for a while?
>> 
>> I never use 'git pull' for merging, and all the time with rebasing, so
>> what's the point? I mean, whenever I do 'git pull' I mean 'git pull
>> --rebase', and whenever I need to merge, I exclusively use'git merge'.
>
> So you can remove that configuration.

Sorry, I can't, see below.

>
> And afterwareds set pull.rebase=true so you don't need to specify
> --rebase.

I don't get it. What's the point using pull.rebase=true instead of
pull.rebase=merges? The former is plain total disaster in my opinion as
it silently breaks history shape. I'd rather suggest to make
pull.rebase=true a synonym for pull.rebase=merges.

Thanks,
-- Sergey Organov

Re: The git spring cleanup challenge

[Felipe Contreras]

Sergey Organov wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > Sergey Organov wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> > Sergey Organov wrote:

> >> >> [pull]
> >> >> 	rebase = merges
> >> >
> >> > Can you do `git pull --rebase=merges` for a while?
> >> 
> >> I never use 'git pull' for merging, and all the time with rebasing, so
> >> what's the point? I mean, whenever I do 'git pull' I mean 'git pull
> >> --rebase', and whenever I need to merge, I exclusively use'git merge'.
> >
> > So you can remove that configuration.
> 
> Sorry, I can't, see below.
> 
> > And afterwareds set pull.rebase=true so you don't need to specify
> > --rebase.
> 
> I don't get it. What's the point using pull.rebase=true instead of
> pull.rebase=merges? The former is plain total disaster in my opinion as
> it silently breaks history shape.

I think there's some confusion here.

You said you always did `git pull --rebase`, not
`git pull --rebase=merges`.

The equivalent configurations are:

  git pull --rebase		=> pull.rebase=true
  git pull --rebase=merges	=> pull.rebase=merges

If you can't live without the functionality `pull.rebase=merges` gives
you, that means you have to type `git pull --rebase=merges` if you don't
have such configuration.

Cheers.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Sergey Organov wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> > Sergey Organov wrote:
>> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> >> > Sergey Organov wrote:
>
>> >> >> [pull]
>> >> >> 	rebase = merges
>> >> >
>> >> > Can you do `git pull --rebase=merges` for a while?
>> >> 
>> >> I never use 'git pull' for merging, and all the time with rebasing, so
>> >> what's the point? I mean, whenever I do 'git pull' I mean 'git pull
>> >> --rebase', and whenever I need to merge, I exclusively use'git merge'.
>> >
>> > So you can remove that configuration.
>> 
>> Sorry, I can't, see below.
>> 
>> > And afterwareds set pull.rebase=true so you don't need to specify
>> > --rebase.
>> 
>> I don't get it. What's the point using pull.rebase=true instead of
>> pull.rebase=merges? The former is plain total disaster in my opinion as
>> it silently breaks history shape.
>
> I think there's some confusion here.
>
> You said you always did `git pull --rebase`, not
> `git pull --rebase=merges`.

Yep, I was lazy and didn't say `git pull --rebase=merges`, sorry for
confusion.

Though in fact my phrase was meant to stress that I use rebase as
opposed to merge, and I left the details, in fact because I thought
--rebase=merges sounds even more confusing in this context.

Thanks,
-- Sergey Organov

Re: The git spring cleanup challenge

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

>>> [push]
>>> 	default = simple
>>
>> This is the default, you don't need it.
>
> Yep, a remnant from the past.

This reminds me of something.

This particular remnant is there because the user was an early
adopter from the days before the 'simple' setting was made the
default, and it is a common pattern in our configuration variable
settings.  We introduce a knob to allow early adopters to experience
new settings, and after a while, one of them may become the default,
and at that point, the setting the user has appears redundant.

If we had a central registry of configuration variables and their
default values (there isn't one), one could write a configuration
linter to point out "you have this set, but it is the default these
days" to remind you, which sometimes may be useful.

I say "sometimes" because the reason why the user has a seemingly
redundant setting may be because the default for the variable in
question is planned to change, and the user has it set to keep the
current default---the opposite of the 'early adopter' use case.

Being reminded may still be useful in such a case, but the linter
tool certainly should not make any change blindly in the name of
removing redundant setting without consulting the user.

Re: The git spring cleanup challenge

[Elijah Newren]

On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov <sorganov@gmail.com> wrote:
>
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
> > Hello,
> >
>
> [...]
>
> > These are the configurations I've chosen:
> >
> >   [merge]
> >     conflictstyle = diff3
> >   [sendemail]
> >     smtpserver = /usr/bin/msmtp
> >
>
> [pull]
>         rebase = merges
> [push]
>         default = simple
> [rerere]
>         enabled = true
>         autoupdate = true
> [diff]
>         algorithm = patience

Any reason for patience vs. histogram?

> [merge]
>         conflictStyle = diff3
>

Anyway, here's my list to join in on the fun...

[branch]
        sort = authordate
[alias]
        brief = !git log --no-walk --abbrev=12 --pretty=reference
[log]
        mailmap = true
[merge]
        conflictStyle = diff3
        directoryRenames = true
[protocol]
        version = 2
[feature]
        experimental = true
[pull]
        twohead = ort
[diff]
        renameLimit = 3000

(I have branch.sort=committerdate on another machine; not sure why I
was inconsistent, and yes now that I look at it I'm pretty sure two of
these have since become the default.)

Re: The git spring cleanup challenge

[Felipe Contreras]

Junio C Hamano wrote:
> Sergey Organov <sorganov@gmail.com> writes:
> 
> >>> [push]
> >>> 	default = simple
> >>
> >> This is the default, you don't need it.
> >
> > Yep, a remnant from the past.
> 
> This reminds me of something.
> 
> This particular remnant is there because the user was an early
> adopter from the days before the 'simple' setting was made the
> default, and it is a common pattern in our configuration variable
> settings.  We introduce a knob to allow early adopters to experience
> new settings, and after a while, one of them may become the default,
> and at that point, the setting the user has appears redundant.
> 
> If we had a central registry of configuration variables and their
> default values (there isn't one), one could write a configuration
> linter to point out "you have this set, but it is the default these
> days" to remind you, which sometimes may be useful.
> 
> I say "sometimes" because the reason why the user has a seemingly
> redundant setting may be because the default for the variable in
> question is planned to change, and the user has it set to keep the
> current default---the opposite of the 'early adopter' use case.

Long time ago I proposed a core.mode configuration that would be useful
for this predicament too [1].

When a configuration is planned to change, git_mode = MODE_NEXT would
make the new values the default.

Therefore the linter could do:

  git_mode = MODE_CURRENT;
  git_config_default_get.. &old_default);

  git_mode = MODE_NEXT;
  git_config_default_get.. &new_default);

If the values are the same, that means there's no plans to change the
default, and therefore it's safe to delete the configuration if the user
has the same value.

Cheers.

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

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Felipe Contreras]

Elijah Newren wrote:
> On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov <sorganov@gmail.com> wrote:

> > [diff]
> >         algorithm = patience
> 
> Any reason for patience vs. histogram?

Is histogram better than default?

> > [merge]
> >         conflictStyle = diff3
> >
> 
> Anyway, here's my list to join in on the fun...
> 
> [branch]
>         sort = authordate

Nice. I didn't know that existed.

I have `tag.sort = -version:refname`, and after a few days without I'm
wondering why it isn't the default.

> [alias]
>         brief = !git log --no-walk --abbrev=12 --pretty=reference

I find it odd that you prefer `git log --no-walk` over
`git show --quiet`.

> [log]
>         mailmap = true

Another one that I don't see why it isn't the default.

Cheers.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

> I'm second here. Wanted to get rid of some recorded resolutions, but
> didn't find a suitable way to.

J6t gave a good summary on a side thread.  "rerere forget" followed
by "checkout -m" is your friend (alternatively you can redo the
operation that applied a "wrong" resolution after doing the "rerere
forget" step, of course).

Re: The git spring cleanup challenge

[Elijah Newren]

On Wed, Jun 2, 2021 at 6:36 PM Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>
> Elijah Newren wrote:
> > On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov <sorganov@gmail.com> wrote:
>
> > > [diff]
> > >         algorithm = patience
> >
> > Any reason for patience vs. histogram?
>
> Is histogram better than default?

Yes, definitely.  I think diff.algorithm should default to histogram,
personally.

See also commits 85551232b56e (perf: compare diff algorithms,
2012-03-06) and c8017176ac8f (merge-ort: use histogram diff,
2020-12-13).

> > > [merge]
> > >         conflictStyle = diff3
> > >
> >
> > Anyway, here's my list to join in on the fun...
> >
> > [branch]
> >         sort = authordate
>
> Nice. I didn't know that existed.
>
> I have `tag.sort = -version:refname`, and after a few days without I'm
> wondering why it isn't the default.
>
> > [alias]
> >         brief = !git log --no-walk --abbrev=12 --pretty=reference
>
> I find it odd that you prefer `git log --no-walk` over
> `git show --quiet`.

Why?  Both log and show require an extra flag, so why should the
choice matter or be surprising?

I happen to use log a lot more than show, so I think in terms of
adding flags to git log rather than the ones I need to add to git
show.  Not a big deal either way, though.

> > [log]
> >         mailmap = true
>
> Another one that I don't see why it isn't the default.

It is the default and has been for a couple years; see f3eda90ffc10
(log: really flip the --mailmap default, 2019-08-01).  I just never
cleaned up my config.

Re: The git spring cleanup challenge

[Ævar Arnfjörð Bjarmason]

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.

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

Part of that goes against what I was arguing for in [1], but I suppose
if that's a problem we could always optionally compile these in (in
Go-like fashion), while retaining the semantics.

The advantage of doing that is that you don't have to bless one set of
aliases, e.g. you could have cvs-like.cfg, svn-like.cfg etc.

1. https://lore.kernel.org/git/87czvoowg2.fsf@evledraar.gmail.com/

Re: The git spring cleanup challenge

[Ævar Arnfjörð Bjarmason]

On Tue, Jun 01 2021, Felipe Contreras wrote:

>   1. Remove all the configuration that is not essential (just leave
>      user.name and user.email or equivalent)
>   2. Pick 2 configurations you think you can't live without. You are not
>      allowed to change them afterwards.
>   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.

This proposal is somewhere between picking which 2 of your 4 kids gets
to live and asking an alcoholic to stop drinking for a week just so he
can tell you at the end what his favorite drinks are :)

So I skipped the "disable most config", but for what it's worth I think
I'd miss these the most, I couldn't pick just N favorites, sorry:

 * diff.colorMoved=true: super useful, but I'd be vary of turning it on
   by default in its current form. E.g. on gcc.git's changelog files it
   has really pathological performance characteristics.

 * rebase.rescheduleFailedExec=true: Relatively new, but I'd find it
   hard to live without this now.

 * rerere.*: others have mentioned "should be enabled by default".

   But on that topic I set gc.rerereResolved="1 year ago", with
   managing/merging topics in git.git the default of 60 days is way too
   aggressive.

 * merge.defaultToUpstream: ditto other discussion, should be "true" by
   default.

 * checkout.defaultRemote=origin: I introduced this, so I'm biased, but
   I find it super useful. Usually because I do "git branch -m
   new-branch" on master to create topics, and then "git checkout
   master" to get a master back (or use the existing one).

 * commit.verbose=true: so you know what you're looking at in doing in
   "git commit --amend".

 * grep.patternType=perl: Another personal soap box (but really, BRE
   anywhere sucks).

I also have a bunch of aliases that would not be useful to a general
audience, but which I find I can't live without, some of the most
commonly used ones:

    # Log with "less" n/p already going to the next/prev commit
    log-psfd = "!f() { PAGER=\"less -p'^commit'\" git log -p --stat --full-diff $@; }; f"
    # cutesy commit aliases (I guess "commit" is both "ci" and "c" here, but...)
    cif = commit --fixup
    cis = commit --squash
    ca = commit --amend
    cane = commit --amend --no-edit

Similarly rebase is "r", "--interactive" is "ri", "--abort", and
"--continue" are "ra" and "rc".

If anyone's interested in the rest / full set:
https://github.com/avar/dotfiles/blob/master/.gitconfig
    

Re: The git spring cleanup challenge

[Sergey Organov]

Elijah Newren <newren@gmail.com> writes:

> On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov <sorganov@gmail.com> wrote:
>>
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>> > Hello,
>> >
>>
>> [...]
>>
>> > These are the configurations I've chosen:
>> >
>> >   [merge]
>> >     conflictstyle = diff3
>> >   [sendemail]
>> >     smtpserver = /usr/bin/msmtp
>> >
>>
>> [pull]
>>         rebase = merges
>> [push]
>>         default = simple
>> [rerere]
>>         enabled = true
>>         autoupdate = true
>> [diff]
>>         algorithm = patience
>
> Any reason for patience vs. histogram?

No, I only tried the 'patience', didn't try 'histogram'.

-- Sergey Organov

Re: The git spring cleanup challenge

[Felipe Contreras]

Elijah Newren wrote:
> On Wed, Jun 2, 2021 at 6:36 PM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> >
> > Elijah Newren wrote:
> > > On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov <sorganov@gmail.com> wrote:
> >
> > > > [diff]
> > > >         algorithm = patience
> > >
> > > Any reason for patience vs. histogram?
> >
> > Is histogram better than default?
> 
> Yes, definitely.  I think diff.algorithm should default to histogram,
> personally.
> 
> See also commits 85551232b56e (perf: compare diff algorithms,
> 2012-03-06) and c8017176ac8f (merge-ort: use histogram diff,
> 2020-12-13).

Interesting. I'll give it a try after this month.

> > > > [merge]
> > > >         conflictStyle = diff3
> > > >
> > >
> > > Anyway, here's my list to join in on the fun...
> > >
> > > [branch]
> > >         sort = authordate
> >
> > Nice. I didn't know that existed.
> >
> > I have `tag.sort = -version:refname`, and after a few days without I'm
> > wondering why it isn't the default.
> >
> > > [alias]
> > >         brief = !git log --no-walk --abbrev=12 --pretty=reference
> >
> > I find it odd that you prefer `git log --no-walk` over
> > `git show --quiet`.
> 
> Why?  Both log and show require an extra flag, so why should the
> choice matter or be surprising?

Because log is to list a log, and show is to show a single commit. --no-walk
makes sense in addition to --stdin for example.

A log with a single entry doesn't seem like a log to me. But to each his
own.

> I happen to use log a lot more than show, so I think in terms of
> adding flags to git log rather than the ones I need to add to git
> show.  Not a big deal either way, though.

I'm the opposite, in fact, I barely use git log. When I want to see
history I use gitk, and when I want to see a single commit `git show`.

 9% show
 7% v # alias for gitk
 2% log

> > > [log]
> > >         mailmap = true
> >
> > Another one that I don't see why it isn't the default.
> 
> It is the default and has been for a couple years; see f3eda90ffc10
> (log: really flip the --mailmap default, 2019-08-01).  I just never
> cleaned up my config.

Ohhh, that makes sense.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> I'm second here. Wanted to get rid of some recorded resolutions, but
>> didn't find a suitable way to.
>
> J6t gave a good summary on a side thread.  "rerere forget" followed
> by "checkout -m" is your friend (alternatively you can redo the
> operation that applied a "wrong" resolution after doing the "rerere
> forget" step, of course).

Well, I was not in the middle of any merge when I wanted the feature,
and "forget", according to its documentation, deals with "the current
conflict".

As far as I recall, I wanted rerere to just forget everything it ever
knew about merge resolutions for all the paths in particular
sub-directory, before I even start the merge, and I rather ended up
doing the merge in a fresh clone.

Thanks,
-- Sergey Organov

Re: The git spring cleanup challenge

[Felipe Contreras]

Æ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 have been using git without aliases for 2 days, and I'm already fed up.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Sergey Organov]

Felipe Contreras <felipe.contreras@gmail.com> writes:


[...]

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

I guess 'ci' historically means "check in", as opposed to 'co' meaning
"check out", probably in RCS.

Thanks,
-- Sergey Organov

Re: The git spring cleanup challenge

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> 
> On Tue, Jun 01 2021, Felipe Contreras wrote:
> 
> >   1. Remove all the configuration that is not essential (just leave
> >      user.name and user.email or equivalent)
> >   2. Pick 2 configurations you think you can't live without. You are not
> >      allowed to change them afterwards.
> >   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.
> 
> This proposal is somewhere between picking which 2 of your 4 kids gets
> to live and asking an alcoholic to stop drinking for a week just so he
> can tell you at the end what his favorite drinks are :)

Yeah, but if you can't enjoy life without alcohol, you probably have a
problem.

Are you saying vanilla git is *that* bad?

> So I skipped the "disable most config", but for what it's worth I think
> I'd miss these the most, I couldn't pick just N favorites, sorry:
> 
>  * diff.colorMoved=true: super useful, but I'd be vary of turning it on
>    by default in its current form. E.g. on gcc.git's changelog files it
>    has really pathological performance characteristics.

Very nice! I didn't know about it. I'll pick it for my third day.

>  * merge.defaultToUpstream: ditto other discussion, should be "true" by
>    default.

That is the default. I used it as an example of a configuration that
changed default (I did it in 2014).

(I just noticed the documentation of the config wasn't updated).

>  * checkout.defaultRemote=origin: I introduced this, so I'm biased, but
>    I find it super useful. Usually because I do "git branch -m
>    new-branch" on master to create topics, and then "git checkout
>    master" to get a master back (or use the existing one).

That is useful, but I don't think it's aptly named, it should be
something like checkout.autoUpstream. The name of the default branch
belongs elsewhere.

I would say core.defaultRemote.

Right now for example `git fetch` defaults to a hard-coded "origin".
Doesn't make much sense that the remote for automatic upstream checkout
can be configured, but not the one `git fetch` uses.

>  * commit.verbose=true: so you know what you're looking at in doing in
>    "git commit --amend".

Aha! My alias had `commit -v` but I would want this on all commit
commands.

Moreover, I was thinking on suggesting this by default. Who would it
hurt?

>  * grep.patternType=perl: Another personal soap box (but really, BRE
>    anywhere sucks).

Nice. `git grep` is the #2 command I use the most, and I often need to
specify another regexp because the basic one doesn't understand what I'm
trying to do.

> I also have a bunch of aliases that would not be useful to a general
> audience, but which I find I can't live without, some of the most
> commonly used ones:
> 
>     # Log with "less" n/p already going to the next/prev commit
>     log-psfd = "!f() { PAGER=\"less -p'^commit'\" git log -p --stat --full-diff $@; }; f"

Very neat.

> Similarly rebase is "r", "--interactive" is "ri", "--abort", and
> "--continue" are "ra" and "rc".

I have almost the same, except rbi, rbc, and rba. My 'r' is reset, but
since I use rebase more often I guess I should switch them up.

Theres are a couple of mine:

  advance = merge --ff-only
  undo = reset --hard @{1}
  
> If anyone's interested in the rest / full set:
> https://github.com/avar/dotfiles/blob/master/.gitconfig

Is thata private repo?

Here are mine:

https://github.com/felipec/dotfiles/blob/master/.gitconfig

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Ævar Arnfjörð Bjarmason]

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/

Re: The git spring cleanup challenge

[Ævar Arnfjörð Bjarmason]

On Thu, Jun 03 2021, Felipe Contreras wrote:

> Ævar Arnfjörð Bjarmason wrote:
>> So I skipped the "disable most config", but for what it's worth I think
>> I'd miss these the most, I couldn't pick just N favorites, sorry:
>> 
>>  * diff.colorMoved=true: super useful, but I'd be vary of turning it on
>>    by default in its current form. E.g. on gcc.git's changelog files it
>>    has really pathological performance characteristics.
>
> Very nice! I didn't know about it. I'll pick it for my third day.

It makes patch review a lot easier, and also integrates nicely with -w.

>>  * merge.defaultToUpstream: ditto other discussion, should be "true" by
>>    default.
>
> That is the default. I used it as an example of a configuration that
> changed default (I did it in 2014).
>
> (I just noticed the documentation of the config wasn't updated).

Ha! Maybe it's leftover from before then, or I missed that in the
not-updated docs more recently.

>>  * checkout.defaultRemote=origin: I introduced this, so I'm biased, but
>>    I find it super useful. Usually because I do "git branch -m
>>    new-branch" on master to create topics, and then "git checkout
>>    master" to get a master back (or use the existing one).
>
> That is useful, but I don't think it's aptly named, it should be
> something like checkout.autoUpstream. The name of the default branch
> belongs elsewhere.
>
> I would say core.defaultRemote.
>
> Right now for example `git fetch` defaults to a hard-coded "origin".
> Doesn't make much sense that the remote for automatic upstream checkout
> can be configured, but not the one `git fetch` uses.

I think there was some bikeshedding around that time. I share the
sentiment, but worry about "core" over-configuring such a
thing. E.g. wanting "checkout" to search a "upstream" and "origin" in
that order (not that it supports a list right now, but could) != wanting
"init" to use "upstream" instead of "origin" by default.

>>  * commit.verbose=true: so you know what you're looking at in doing in
>>    "git commit --amend".
>
> Aha! My alias had `commit -v` but I would want this on all commit
> commands.
>
> Moreover, I was thinking on suggesting this by default. Who would it
> hurt?

E.g. "git rebase -i" with "reword" now becomes a lot more verbose, I
think it's a feature, but others might disagree.

It also exposes various edge cases around our parsing of the diff
v.s. commit message content in our apply.c etc. code, e.g. say you want
to blindly search-replace "diff" with "difference" in your commit
messages. You'll now change the "diff --git" line to "difference --git",
and now "commit" won't detect that it's the patch part anymore, and
merge that diff into your commit message itself.

I can't remember if we pick up on "diff --git" exactly, IIRC, but
anyway, whatever part of the format you need to screw with, the point
stands. I've run into mistakes like that in the past, one recently made
it to this ML.

>>  * grep.patternType=perl: Another personal soap box (but really, BRE
>>    anywhere sucks).
>
> Nice. `git grep` is the #2 command I use the most, and I often need to
> specify another regexp because the basic one doesn't understand what I'm
> trying to do.

Yeah, it should be at least ERE by default, Something for Git v3.0 ...?

>> I also have a bunch of aliases that would not be useful to a general
>> audience, but which I find I can't live without, some of the most
>> commonly used ones:
>> 
>>     # Log with "less" n/p already going to the next/prev commit
>>     log-psfd = "!f() { PAGER=\"less -p'^commit'\" git log -p --stat --full-diff $@; }; f"
>
> Very neat.

I think similar to your "git help xyz" patches having coloring, we
really should consider things like that by default knowing that we're
invoking "less". I.e. if we got over the notion that our job is just to
throw data over the wall to "man" or the pager without any further
tweaking or integration.

>> Similarly rebase is "r", "--interactive" is "ri", "--abort", and
>> "--continue" are "ra" and "rc".
>
> I have almost the same, except rbi, rbc, and rba. My 'r' is reset, but
> since I use rebase more often I guess I should switch them up.
>
> Theres are a couple of mine:
>
>   advance = merge --ff-only
>   undo = reset --hard @{1}
>   
>> If anyone's interested in the rest / full set:
>> https://github.com/avar/dotfiles/blob/master/.gitconfig
>
> Is thata private repo?
>
> Here are mine:
>
> https://github.com/felipec/dotfiles/blob/master/.gitconfig

Yes, it was private[1]. I've made it public again.

1. It used to be public, but then the security/auditing people at an
   ex-job kept pestering me about me hardcoding über-secret company data
   in public GitHub repos.

   They didn't find questions like "uh, you mean this information we
   advertise in an MX lookup to our public nameservers?", or "yes,
   that's my company E-Mail address in a config file, my co-workers have
   the same info on linkedin" all that convincing. Anyway, it's back now
   :)

Re: The git spring cleanup challenge

[Phillip Wood]

Hi Ævar

On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:
> 
> On Thu, Jun 03 2021, Felipe Contreras wrote:
> 
>> Ævar Arnfjörð Bjarmason wrote:
>>> So I skipped the "disable most config", but for what it's worth I think
>>> I'd miss these the most, I couldn't pick just N favorites, sorry:
>>>
>>>   * diff.colorMoved=true: super useful, but I'd be vary of turning it on
>>>     by default in its current form. E.g. on gcc.git's changelog files it
>>>     has really pathological performance characteristics.

Would you be able say a bit more about this so I can try and reproduce 
it please. I'm working on some patches [1] to improve the performance of 
`diff --color-moved` and `diff --color-moved-ws` and it would be good to 
test them on a problematic repo. At the moment I diffing two releases of 
git to test performance on a large diff. I just cloned the last 18 
months of gcc.git and Changelog seems to just be appended to.

>> Very nice! I didn't know about it. I'll pick it for my third day.
> 
> It makes patch review a lot easier, and also integrates nicely with -w.

I find --color-moved-ws=allow-indentation-change helpful as well (it is 
quite a bit slower at the moment but I have some patches to bring it up 
to the speed of the other --color-moved modes.

[1] https://github.com/phillipwood/git/tree/wip/diff-color-moved-tweaks

> [...]
>>>   * commit.verbose=true: so you know what you're looking at in doing in
>>>     "git commit --amend".
>>
>> Aha! My alias had `commit -v` but I would want this on all commit
>> commands.
>>
>> Moreover, I was thinking on suggesting this by default. Who would it
>> hurt?
> 
> E.g. "git rebase -i" with "reword" now becomes a lot more verbose, I
> think it's a feature, but others might disagree.
> 
> It also exposes various edge cases around our parsing of the diff
> v.s. commit message content in our apply.c etc. code, e.g. say you want
> to blindly search-replace "diff" with "difference" in your commit
> messages. You'll now change the "diff --git" line to "difference --git",
> and now "commit" won't detect that it's the patch part anymore, and
> merge that diff into your commit message itself.
> 
> I can't remember if we pick up on "diff --git" exactly, IIRC, but
> anyway, whatever part of the format you need to screw with, the point
> stands. I've run into mistakes like that in the past, one recently made
> it to this ML.

I think the problem occurs if the scissors line gets messed up when 
editing the commit message

>[...] 
>>> I also have a bunch of aliases that would not be useful to a general
>>> audience, but which I find I can't live without, some of the most
>>> commonly used ones:
>>>
>>>      # Log with "less" n/p already going to the next/prev commit
>>>      log-psfd = "!f() { PAGER=\"less -p'^commit'\" git log -p --stat --full-diff $@; }; f"
>>
>> Very neat.
> 
> I think similar to your "git help xyz" patches having coloring, we
> really should consider things like that by default knowing that we're
> invoking "less". I.e. if we got over the notion that our job is just to
> throw data over the wall to "man" or the pager without any further
> tweaking or integration.

Speaking personally it is not that I think that we should just throw 
data over the all to "man" but that if colors are a good idea we should 
be thinking about the whole ecosystem and working with distributions or 
the man authors to ensure all programs and users benefit from it not 
just git.

Best Wishes

Phillip

Re: The git spring cleanup challenge

[Ævar Arnfjörð Bjarmason]

On Thu, Jun 03 2021, Phillip Wood wrote:

> Hi Ævar
>
> On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Jun 03 2021, Felipe Contreras wrote:
>> 
>>> Ævar Arnfjörð Bjarmason wrote:
>>>> So I skipped the "disable most config", but for what it's worth I think
>>>> I'd miss these the most, I couldn't pick just N favorites, sorry:
>>>>
>>>>   * diff.colorMoved=true: super useful, but I'd be vary of turning it on
>>>>     by default in its current form. E.g. on gcc.git's changelog files it
>>>>     has really pathological performance characteristics.
>
> Would you be able say a bit more about this so I can try and reproduce
> it please. I'm working on some patches [1] to improve the performance
> of `diff --color-moved` and `diff --color-moved-ws` and it would be
> good to test them on a problematic repo. At the moment I diffing two
> releases of git to test performance on a large diff. I just cloned the
> last 18 months of gcc.git and Changelog seems to just be appended to.

I misremembered the gcc.git ChangeLog issue, sorry. That's about
something else entirely.

The issue with the color moved code can just be reproduced on most large
diffs, e.g. on git.git:
    
    $ time git diff --color-moved=true v2.25.0..v2.30.0 >/dev/null
    real    0m10.112s
    $ time git diff --color-moved=false v2.25.0..v2.30.0 >/dev/null
    real    0m0.939s

So 10x slower, and e.g. diffing from v2.22.0 makes it 25s and 1.1s,
respectively.

In some sense that slowness is expected, it simly takes time to compute
this. I think for turning it on by default we should have something like
the diff.renameLimit, and change the default to some "auto" that would
punt out if it was taking too long to compute.

I run with it by default so this doesn't bother me, but I think it's
probably a semi-common use-case of some people to e.g. diff the last N
releases of Linux, and then use their pager to search around in the
diff.

We don't want commands like that to take 25s instead of 1s, but I think
it would be fine (and we should) warn that we aborted on the color move
if it's otherwise the default.

Otherwise it'll take 1s, and if you normally depend on it you'll
conclude that some code you're looking at wasn't moved, which would also
suck, better to punt on it and warn, just like the diff.renameLimit.


>>> Very nice! I didn't know about it. I'll pick it for my third day.
>> It makes patch review a lot easier, and also integrates nicely with
>> -w.
>
> I find --color-moved-ws=allow-indentation-change helpful as well (it
> is quite a bit slower at the moment but I have some patches to bring
> it up to the speed of the other --color-moved modes.
>
> [1] https://github.com/phillipwood/git/tree/wip/diff-color-moved-tweaks

Nice, I didn't know about that option. Will try it.

Re: The git spring cleanup challenge

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jun 03 2021, Felipe Contreras wrote:

> >>  * checkout.defaultRemote=origin: I introduced this, so I'm biased, but
> >>    I find it super useful. Usually because I do "git branch -m
> >>    new-branch" on master to create topics, and then "git checkout
> >>    master" to get a master back (or use the existing one).
> >
> > That is useful, but I don't think it's aptly named, it should be
> > something like checkout.autoUpstream. The name of the default branch
> > belongs elsewhere.
> >
> > I would say core.defaultRemote.
> >
> > Right now for example `git fetch` defaults to a hard-coded "origin".
> > Doesn't make much sense that the remote for automatic upstream checkout
> > can be configured, but not the one `git fetch` uses.
> 
> I think there was some bikeshedding around that time. I share the
> sentiment, but worry about "core" over-configuring such a
> thing.

I don't see a need for core.defaultRemote, but I don't see a need for
checkout.defaultRemote either.

Just have `checkout.autoUpstream = true` and hardcode *both* to "origin".

> >>  * commit.verbose=true: so you know what you're looking at in doing in
> >>    "git commit --amend".
> >
> > Aha! My alias had `commit -v` but I would want this on all commit
> > commands.
> >
> > Moreover, I was thinking on suggesting this by default. Who would it
> > hurt?
> 
> E.g. "git rebase -i" with "reword" now becomes a lot more verbose, I
> think it's a feature, but others might disagree.
> 
> It also exposes various edge cases around our parsing of the diff
> v.s. commit message content in our apply.c etc. code, e.g. say you want
> to blindly search-replace "diff" with "difference" in your commit
> messages. You'll now change the "diff --git" line to "difference --git",
> and now "commit" won't detect that it's the patch part anymore, and
> merge that diff into your commit message itself.
> 
> I can't remember if we pick up on "diff --git" exactly, IIRC, but
> anyway, whatever part of the format you need to screw with, the point
> stands. I've run into mistakes like that in the past, one recently made
> it to this ML.

I've personally never have had a problem with it.

Sure, it *might* have some issues, but any change does. That's not a
very strong arugment against making it the default.

> >>  * grep.patternType=perl: Another personal soap box (but really, BRE
> >>    anywhere sucks).
> >
> > Nice. `git grep` is the #2 command I use the most, and I often need to
> > specify another regexp because the basic one doesn't understand what I'm
> > trying to do.
> 
> Yeah, it should be at least ERE by default, Something for Git v3.0 ...?
> 
> >> I also have a bunch of aliases that would not be useful to a general
> >> audience, but which I find I can't live without, some of the most
> >> commonly used ones:
> >> 
> >>     # Log with "less" n/p already going to the next/prev commit
> >>     log-psfd = "!f() { PAGER=\"less -p'^commit'\" git log -p --stat --full-diff $@; }; f"
> >
> > Very neat.
> 
> I think similar to your "git help xyz" patches having coloring, we
> really should consider things like that by default knowing that we're
> invoking "less". I.e. if we got over the notion that our job is just to
> throw data over the wall to "man" or the pager without any further
> tweaking or integration.

Perhaps. I think defaults should be tried-and-true. Only after a
considerable number of people have tried them should they become
default.

I have no problem with something like the above being a default, but
only when the user has specified these kinds of features.

Maybe with

  [core]
    mode = fancy

> >> Similarly rebase is "r", "--interactive" is "ri", "--abort", and
> >> "--continue" are "ra" and "rc".
> >
> > I have almost the same, except rbi, rbc, and rba. My 'r' is reset, but
> > since I use rebase more often I guess I should switch them up.
> >
> > Theres are a couple of mine:
> >
> >   advance = merge --ff-only
> >   undo = reset --hard @{1}
> >   
> >> If anyone's interested in the rest / full set:
> >> https://github.com/avar/dotfiles/blob/master/.gitconfig
> >
> > Is thata private repo?
> >
> > Here are mine:
> >
> > https://github.com/felipec/dotfiles/blob/master/.gitconfig
> 
> Yes, it was private[1]. I've made it public again.
> 
> 1. It used to be public, but then the security/auditing people at an
>    ex-job kept pestering me about me hardcoding über-secret company data
>    in public GitHub repos.
> 
>    They didn't find questions like "uh, you mean this information we
>    advertise in an MX lookup to our public nameservers?", or "yes,
>    that's my company E-Mail address in a config file, my co-workers have
>    the same info on linkedin" all that convincing. Anyway, it's back now
>    :)

Yeah, it's surpsingly difficult to convince some people of the most
obvious things. I rather have a private branch on my dotfiles, where I
don't have anything sensitive really, just stuff I'm sure others won't
find useful.

Cheers.

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Phillip Wood]

Hi Ævar
On 03/06/2021 17:44, Ævar Arnfjörð Bjarmason wrote:
> 
> On Thu, Jun 03 2021, Phillip Wood wrote:
> 
>> Hi Ævar
>>
>> On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:
>>> On Thu, Jun 03 2021, Felipe Contreras wrote:
>>>
>>>> Ævar Arnfjörð Bjarmason wrote:
>>>>> So I skipped the "disable most config", but for what it's worth I think
>>>>> I'd miss these the most, I couldn't pick just N favorites, sorry:
>>>>>
>>>>>    * diff.colorMoved=true: super useful, but I'd be vary of turning it on
>>>>>      by default in its current form. E.g. on gcc.git's changelog files it
>>>>>      has really pathological performance characteristics.
>>
>> Would you be able say a bit more about this so I can try and reproduce
>> it please. I'm working on some patches [1] to improve the performance
>> of `diff --color-moved` and `diff --color-moved-ws` and it would be
>> good to test them on a problematic repo. At the moment I diffing two
>> releases of git to test performance on a large diff. I just cloned the
>> last 18 months of gcc.git and Changelog seems to just be appended to.
> 
> I misremembered the gcc.git ChangeLog issue, sorry. That's about
> something else entirely.
> 
> The issue with the color moved code can just be reproduced on most large
> diffs, e.g. on git.git:
>      
>      $ time git diff --color-moved=true v2.25.0..v2.30.0 >/dev/null
>      real    0m10.112s
>      $ time git diff --color-moved=false v2.25.0..v2.30.0 >/dev/null
>      real    0m0.939s

"Big diffs are slow with --color-moved" is the problem I've been 
focusing on. With my patches I see the time for --color-moved=true go 
down from 16s to 4.3s for that example. --color-moved=false takes 0.8s 
so the --color-moved=true is still quite a bit slower but it's not as 
bad. --color-moved-ws=allow-indentation-change goes from 8 minutes(!) to 
6 seconds. I'm seeing a slight (few percent) slowdown for `git log 
--patch --no-merges -n1000` though which I'd like to avoid.

> So 10x slower, and e.g. diffing from v2.22.0 makes it 25s and 1.1s,
> respectively.
>
> In some sense that slowness is expected, it simly takes time to compute
> this. I think for turning it on by default we should have something like
> the diff.renameLimit, and change the default to some "auto" that would
> punt out if it was taking too long to compute.
> 
> I run with it by default so this doesn't bother me, but I think it's
> probably a semi-common use-case of some people to e.g. diff the last N
> releases of Linux, and then use their pager to search around in the
> diff.

Yeah I can see people doing that.

> We don't want commands like that to take 25s instead of 1s, but I think
> it would be fine (and we should) warn that we aborted on the color move
> if it's otherwise the default.
> 
> Otherwise it'll take 1s, and if you normally depend on it you'll
> conclude that some code you're looking at wasn't moved, which would also
> suck, better to punt on it and warn, just like the diff.renameLimit.

That's a nice idea, one other thought I had was to fall back to just 
looking for moved lines within the same file - that would be much faster 
on a large diff with lots of files but maybe it is confusing to 
highlight only some of the moved lines when there are interfile as well 
as intrafile moves.

Best Wishes

Phillip

> 
>>>> Very nice! I didn't know about it. I'll pick it for my third day.
>>> It makes patch review a lot easier, and also integrates nicely with
>>> -w.
>>
>> I find --color-moved-ws=allow-indentation-change helpful as well (it
>> is quite a bit slower at the moment but I have some patches to bring
>> it up to the speed of the other --color-moved modes.
>>
>> [1] https://github.com/phillipwood/git/tree/wip/diff-color-moved-tweaks
> 
> Nice, I didn't know about that option. Will try it.
> 

Re: The git spring cleanup challenge

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jun 03 2021, Felipe Contreras wrote:
> > Ævar Arnfjörð Bjarmason wrote:

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

I really gave this a try, but the problem is that git doesn't even have
a stardard location to install shared files.

I started with $sharedir, but that's not git-specific. Then I added
$gitsharedir which required a bunch of changes to the Makefile, and
eventually I decided against it.

We don't have standard location for shared files. Period.

> In a way this is total bikeshedding, I just think it's worth doing it
> this way up-front.

Yes, maybe so, but git infraestructure is completely unprepared for that
(at this point).

So I just decied to hard-code them [1]

[1] https://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com/

-- 
Felipe Contreras

Re: The git spring cleanup challenge

[Ævar Arnfjörð Bjarmason]

On Fri, Jul 02 2021, Felipe Contreras wrote:

> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Jun 03 2021, Felipe Contreras wrote:
>> > Ævar Arnfjörð Bjarmason wrote:
>
>> >> 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:
>
> I really gave this a try, but the problem is that git doesn't even have
> a stardard location to install shared files.
>
> I started with $sharedir, but that's not git-specific. Then I added
> $gitsharedir which required a bunch of changes to the Makefile, and
> eventually I decided against it.
>
> We don't have standard location for shared files. Period.
>
>> In a way this is total bikeshedding, I just think it's worth doing it
>> this way up-front.
>
> Yes, maybe so, but git infraestructure is completely unprepared for that
> (at this point).
>
> So I just decied to hard-code them [1]
>
> [1] https://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com/

FWIW I only saw this reply after I replied in that thread
... referencing this one.

I haven't tried, but I'd think it wouldn't be a big change. You're
injecting alias.* config directly, you could just inject an
include.path=* in the relevant part of the config machinery instead.

We'd need a new verb like gitdir:* and onbranch:*, maybe system:* or
git:*, we'd then search system:foo.cfg for those relative to our libexec
or /usr/share data, e.g. /usr/lib/git-core/config/foo.cfg

We could then carry those in includes/* in the git.git repo, and to
address the "let's make sure they're there" have a trivial build step
like the command-list.h to build those into a C object. I.e. dog-food on
our own build process and run `git config -f <file> -l -z` for each one,
munge that and spew it into a *.c
file. I.e. include/aliases/svn-like.cfg or whatever.

Then when we can't find a system:* (or whatever it's called)
handle_path_include() we'd consult that list of fallbacks.

I'm not saying it's trivial, just that I think in practice building
consensus for a "one blessed list of hardcoded aliases" is going to be a
very tough sell, and making it optional/configurable/pluggable might
make that sell a lot easier.

Re: The git spring cleanup challenge

[Felipe Contreras]

Ævar Arnfjörð Bjarmason wrote:
> 
> On Fri, Jul 02 2021, Felipe Contreras wrote:
> 
> > Ævar Arnfjörð Bjarmason wrote:
> >> On Thu, Jun 03 2021, Felipe Contreras wrote:
> >> > Ævar Arnfjörð Bjarmason wrote:
> >
> >> >> 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:
> >
> > I really gave this a try, but the problem is that git doesn't even have
> > a stardard location to install shared files.
> >
> > I started with $sharedir, but that's not git-specific. Then I added
> > $gitsharedir which required a bunch of changes to the Makefile, and
> > eventually I decided against it.
> >
> > We don't have standard location for shared files. Period.
> >
> >> In a way this is total bikeshedding, I just think it's worth doing it
> >> this way up-front.
> >
> > Yes, maybe so, but git infraestructure is completely unprepared for that
> > (at this point).
> >
> > So I just decied to hard-code them [1]
> >
> > [1] https://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com/
> 
> FWIW I only saw this reply after I replied in that thread
> ... referencing this one.
> 
> I haven't tried, but I'd think it wouldn't be a big change.

As I explaind the problem is that the build infraestructure is
completely unprepared to install files in /usr/share.

Go ahead and try to add a simple text file to the distribution.

Are you going to put it under /usr/share/git-core? Where are you going
to add it in the git tree? What target is going to install it?

> You're injecting alias.* config directly, you could just inject an
> include.path=* in the relevant part of the config machinery instead.
> 
> We'd need a new verb like gitdir:* and onbranch:*, maybe system:* or
> git:*, we'd then search system:foo.cfg for those relative to our libexec
> or /usr/share data, e.g. /usr/lib/git-core/config/foo.cfg
> 
> We could then carry those in includes/* in the git.git repo, and to
> address the "let's make sure they're there" have a trivial build step
> like the command-list.h to build those into a C object. I.e. dog-food on
> our own build process and run `git config -f <file> -l -z` for each one,
> munge that and spew it into a *.c
> file. I.e. include/aliases/svn-like.cfg or whatever.
> 
> Then when we can't find a system:* (or whatever it's called)
> handle_path_include() we'd consult that list of fallbacks.
> 
> I'm not saying it's trivial, just that I think in practice building
> consensus for a "one blessed list of hardcoded aliases" is going to be a
> very tough sell, and making it optional/configurable/pluggable might
> make that sell a lot easier.

I know, I do see value in this approach, which is why I tried. But when
I saw I was making more changes to the Makefile than the code I decided
to stop.

Moreover, it makes little sense to implement this perfectly if Junio is
simply going to reject it all.

Maybe once we have the "extra" directory it would be more straightforward.

-- 
Felipe Contreras