From: Felipe Contreras <hidden> Date: 2021-06-01 06:24:07
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
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.
From: Đoàn Trần Công Danh <hidden> Date: 2021-06-01 07:47:09
On 2021-06-01 01:24:01-0500, Felipe Contreras [off-list ref] 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
From: Felipe Contreras <hidden> Date: 2021-06-01 10:07:49
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
From: Felipe Contreras <hidden> Date: 2021-06-01 10:48:51
Đoàn Trần Công Danh wrote:
On 2021-06-01 01:24:01-0500, Felipe Contreras [off-list ref] wrote:
quoted
The premise is simple: git.git developers are experts in git, and therefore
they have fine-tuned their ~/.gitconfig to a point that is pretty far
from what any newcomer will experience for a long time.
How long can you survive with a pristine configuration?
Plenty of developers take many things in their configuration for
granted, they forget what the default behavior is, or worse: they forget
they actually have configured log.decorate, and are surprised when they
discover the reason they could not reproduce a bug report.
OK, the person that forgot having log.decorate configured is me.
Right. That's just the most recent instance I could think of, but I'm
sure similar versions have happened to all of us.
quoted
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.
quoted
2. Pick 2 configurations you think you can't live without. You are not
allowed to change them afterwards.
Something is essential when working on constantly integration tree,
I don't want to make my life hard:
* rerere.enabled = true
* rerere.autoupdate = true
If the defaults make your life hard, then shouldn't we change the
defaults?
For starters, which is the command you use? `git merge`? If so, maybe
`git merge` should have a --rerere option to enable rerere. There are
some --rerere-autoupdate, but no --rerere.
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.
quoted
3. Every day you can add 1 additional configuration (and update it the
next day).
4. The moment you add a 4th configuration you lose.
So, my baseline already requires 8 key-value pairs (ignoring alias and
pull.rebase). I'm lost already.
From: Đoàn Trần Công Danh <hidden> Date: 2021-06-01 11:40:21
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
Đoàn Trần Công Danh wrote:
quoted
On 2021-06-01 01:24:01-0500, Felipe Contreras [off-list ref] wrote:
quoted
The premise is simple: git.git developers are experts in git, and therefore
they have fine-tuned their ~/.gitconfig to a point that is pretty far
from what any newcomer will experience for a long time.
How long can you survive with a pristine configuration?
Plenty of developers take many things in their configuration for
granted, they forget what the default behavior is, or worse: they forget
they actually have configured log.decorate, and are surprised when they
discover the reason they could not reproduce a bug report.
OK, the person that forgot having log.decorate configured is me.
Right. That's just the most recent instance I could think of, but I'm
sure similar versions have happened to all of us.
quoted
quoted
Now and then I cleanup my configuration to be reminded of that fact.
Anybody remembers merge.defaultToUpstream, and what `git merge` without
arguments used to do? [1] What about sendemail.chainReplyTo? [2]
It's important that we force ourselves to experience what an
unconfigured git setup looks like, even if it's just for a little bit.
So the challenge is this:
1. Remove all the configuration that is not essential (just leave
user.name and user.email or equivalent)
How about alias? It's part of my muscle memory.
No aliases.
If a new user doesn't have them, neither should you.
All VCSs have default aliases, and I advocated for git to do the same
[1], but it wasn't accepted.
The whole point is to suffer like them.
OK.
quoted
quoted
2. Pick 2 configurations you think you can't live without. You are not
allowed to change them afterwards.
Something is essential when working on constantly integration tree,
I don't want to make my life hard:
* rerere.enabled = true
* rerere.autoupdate = true
If the defaults make your life hard, then shouldn't we change the
defaults?
For starters, which is the command you use? `git merge`? If so, maybe
`git merge` should have a --rerere option to enable rerere. There are
some --rerere-autoupdate, but no --rerere.
I think both pull, merge, rebase, cherry-pick, revert, checkout,
switch, apply, am will be affected by rerere.
Additionally, who doesn't want autoupdate when rerere is manually
enabled?
Dun know. I guess someone applies other people patches
with their rerere logs.
If we all want autoupdate enabled (at least I do), maybe the default
should be flipped, so all you need in your configuration is:
rerere.enabled = true
But, if we are already on this topic... who wants rerere disabled by
default?
quoted
Something is there to shut up advice, I can live without those
configuration value, though (I don't use git-pull these days, anyway):
* pull.rebase = false
Can you train your fingers to type `git pull --no-rebase` for a while?
I don't use git-pull nowaday, so, I don't care.
quoted
Working with patch based need:
* sendemail.smtpserver
* sendemail.smtpencryption
* sendemail.smtpuser
* credential.helper
You could use msmtp instead, but fine, let's make an exception for
transmission of patches (credentials, SMTP, etc.) These are not options
that can be changed in git.gt by default.
But only the essentials, no sendemail.confirm.
quoted
My GnuPG key is Ed25519, and gpg v2 in my machine is named gpg2, so:
* gpg.program = gpg2
You could have an alias in your ~/bin directory:
ln -s /usr/bin/gpg2 ~/bin/gpg
That way you don't need to configure every program.
Fair!
But fine, this is an exception too. The location of programs is not
something that can be changed by default.
quoted
And I would like to try new shiny features:
* feature.experimental = true
Interesting. I didn't know that existed, and I advocated for a
similar configuration: core.mode [2].
But if most newcomers can live without it, I'm sure you can too for a
bit.
The point of trying new shiny features is dogfooding ourselves and
report bugs early, if any.
quoted
quoted
3. Every day you can add 1 additional configuration (and update it the
next day).
4. The moment you add a 4th configuration you lose.
So, my baseline already requires 8 key-value pairs (ignoring alias and
pull.rebase). I'm lost already.
With the exceptions I think you only need these:
* rerere.enabled = true
* rerere.autoupdate = true
From: Felipe Contreras <hidden> Date: 2021-06-01 12:22:02
Đoàn Trần Công Danh wrote:
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
quoted
Đoàn Trần Công Danh wrote:
quoted
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?
quoted
But fine, this is an exception too. The location of programs is not
something that can be changed by default.
quoted
And I would like to try new shiny features:
* feature.experimental = true
Interesting. I didn't know that existed, and I advocated for a
similar configuration: core.mode [2].
But if most newcomers can live without it, I'm sure you can too for a
bit.
The point of trying new shiny features is dogfooding ourselves and
report bugs early, if any.
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.
quoted
quoted
quoted
3. Every day you can add 1 additional configuration (and update it the
next day).
4. The moment you add a 4th configuration you lose.
So, my baseline already requires 8 key-value pairs (ignoring alias and
pull.rebase). I'm lost already.
With the exceptions I think you only need these:
* rerere.enabled = true
* rerere.autoupdate = true
From: Đoàn Trần Công Danh <hidden> Date: 2021-06-01 12:28:36
On 2021-06-01 07:21:57-0500, Felipe Contreras [off-list ref] wrote:
Đoàn Trần Công Danh wrote:
quoted
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
quoted
Đoàn Trần Công Danh wrote:
quoted
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
quoted
quoted
But fine, this is an exception too. The location of programs is not
something that can be changed by default.
quoted
And I would like to try new shiny features:
* feature.experimental = true
Interesting. I didn't know that existed, and I advocated for a
similar configuration: core.mode [2].
But if most newcomers can live without it, I'm sure you can too for a
bit.
The point of trying new shiny features is dogfooding ourselves and
report bugs early, if any.
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.
quoted
quoted
quoted
quoted
3. Every day you can add 1 additional configuration (and update it the
next day).
4. The moment you add a 4th configuration you lose.
So, my baseline already requires 8 key-value pairs (ignoring alias and
pull.rebase). I'm lost already.
With the exceptions I think you only need these:
* rerere.enabled = true
* rerere.autoupdate = true
From: Felipe Contreras <hidden> Date: 2021-06-01 13:14:16
Đoàn Trần Công Danh wrote:
On 2021-06-01 07:21:57-0500, Felipe Contreras [off-list ref] wrote:
quoted
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
From: David Aguilar <hidden> Date: 2021-06-01 21:57:28
On Mon, May 31, 2021 at 11:26 PM Felipe Contreras
[off-list ref] 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
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
From: Felipe Contreras <hidden> Date: 2021-06-02 04:01:25
Bagas Sanjaya wrote:
On 01/06/21 13.24, Felipe Contreras wrote:
quoted
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:
quoted
[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)
quoted
[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:
quoted
[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
From: Đoàn Trần Công Danh <hidden> Date: 2021-06-02 04:13:13
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
quoted
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 ;)
From: Felipe Contreras <hidden> Date: 2021-06-02 04:53:18
Đoàn Trần Công Danh wrote:
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
quoted
quoted
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.
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
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
quoted
quoted
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?
quoted
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.
quoted
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.
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/
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
From: Felipe Contreras <hidden> Date: 2021-06-03 10:07:08
Ævar Arnfjörð Bjarmason wrote:
On Tue, Jun 01 2021, Felipe Contreras wrote:
quoted
Đoàn Trần Công Danh wrote:
quoted
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
quoted
quoted
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?
quoted
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.
quoted
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.
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
From: Felipe Contreras <hidden> Date: 2021-06-03 11:10:25
Ævar Arnfjörð Bjarmason wrote:
On Tue, Jun 01 2021, Felipe Contreras wrote:
quoted
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}
On 2021-06-01 05:48:41-0500, Felipe Contreras [off-list ref] wrote:
quoted
quoted
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?
quoted
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.
quoted
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.
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.
quoted
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/
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.
quoted
* 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.
quoted
* 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.
quoted
* 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.
quoted
* 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 ...?
quoted
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.
quoted
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}
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
:)
Hi Ævar
On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:
On Thu, Jun 03 2021, Felipe Contreras wrote:
quoted
Ævar Arnfjörð Bjarmason wrote:
quoted
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.
quoted
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.
* 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
[...]
quoted
quoted
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
Hi Ævar
On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:
quoted
On Thu, Jun 03 2021, Felipe Contreras wrote:
quoted
Ævar Arnfjörð Bjarmason wrote:
quoted
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.
quoted
quoted
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.
From: Felipe Contreras <hidden> Date: 2021-06-03 17:29:06
Ævar Arnfjörð Bjarmason wrote:
On Thu, Jun 03 2021, Felipe Contreras wrote:
quoted
quoted
* 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".
quoted
quoted
* 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.
quoted
quoted
* 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 ...?
quoted
quoted
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
quoted
quoted
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}
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
Hi Ævar
On 03/06/2021 17:44, Ævar Arnfjörð Bjarmason wrote:
On Thu, Jun 03 2021, Phillip Wood wrote:
quoted
Hi Ævar
On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:
quoted
On Thu, Jun 03 2021, Felipe Contreras wrote:
quoted
Ævar Arnfjörð Bjarmason wrote:
quoted
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
quoted
quoted
quoted
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.
From: Felipe Contreras <hidden> Date: 2021-07-02 10:12:53
Ævar Arnfjörð Bjarmason wrote:
On Thu, Jun 03 2021, Felipe Contreras wrote:
quoted
Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
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.
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.
quoted
In a way this is total bikeshedding, I just think it's worth doing it
this way up-front.
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.
From: Felipe Contreras <hidden> Date: 2021-07-02 21:54:54
Ævar Arnfjörð Bjarmason wrote:
On Fri, Jul 02 2021, Felipe Contreras wrote:
quoted
Ævar Arnfjörð Bjarmason wrote:
quoted
On Thu, Jun 03 2021, Felipe Contreras wrote:
quoted
Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
quoted
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.
quoted
In a way this is total bikeshedding, I just think it's worth doing it
this way up-front.
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