{"thread":{"id":"55814","subject":"The git spring cleanup challenge","startedAt":"2021-06-01T06:24:07Z","lastAt":"2021-07-02T21:54:54Z","messageCount":55,"participants":["Felipe Contreras","Andy","Đoàn Trần Công Danh","David Aguilar","Junio C Hamano","Sergey Organov","Bagas Sanjaya","Johannes Sixt","Elijah Newren","Ævar Arnfjörð Bjarmason","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"426095","messageId":"60b5d281552d6_e359f20828@natae.notmuch","threadId":"55814","inReplyTo":null,"subject":"The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T06:24:01Z","receivedAt":"2021-06-01T06:24:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hello,\n\nThe premise is simple: git.git developers are experts in git, and therefore\nthey have fine-tuned their ~/.gitconfig to a point that is pretty far\nfrom what any newcomer will experience for a long time.\n\nHow long can you survive with a pristine configuration?\n\nPlenty of developers take many things in their configuration for\ngranted, they forget what the default behavior is, or worse: they forget\nthey actually have configured log.decorate, and are surprised when they\ndiscover the reason they could not reproduce a bug report.\n\nNow and then I cleanup my configuration to be reminded of that fact.\n\nAnybody remembers merge.defaultToUpstream, and what `git merge` without\narguments used to do? [1] What about sendemail.chainReplyTo? [2]\n\nIt's important that we force ourselves to experience what an\nunconfigured git setup looks like, even if it's just for a little bit.\n\nSo the challenge is this:\n\n 1. Remove all the configuration that is not essential (just leave\n user.name and user.email or equivalent)\n 2. Pick 2 configurations you think you can't live without. You are not\n allowed to change them afterwards.\n 3. Every day you can add 1 additional configuration (and update it the\n next day).\n 4. The moment you add a 4th configuration you lose.\n\nOnce you've lost, reply to this message with the configuration you could\nnot live without.\n\nThese are the configurations I've chosen:\n\n [merge]\n conflictstyle = diff3\n [sendemail]\n smtpserver = /usr/bin/msmtp\n\nIf if not clear yet, I hope by the end of this little experiment we will\nhave at least one configuration that surely everyone can agree needs to\nbecome a default.\n\nDo you think you can survive one month?\n\nGood luck!\n\n[1] https://lore.kernel.org/git/1296231457-18780-1-git-send-email-felipe.contreras@gmail.com/\n[2] https://lore.kernel.org/git/1369453492-20972-1-git-send-email-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"426098","messageId":"ea3a64bb-7c1e-465a-9639-aedeeb635d0a@gmail.com","threadId":"55814","inReplyTo":"60b5d281552d6_e359f20828@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Andy","fromEmail":"rsstools02@gmail.com","sentAt":"2021-06-01T07:28:30Z","receivedAt":"2021-06-01T07:28:38Z","isPatch":false,"sender":{"key":"rsstools02@gmail.com","avatar":null},"body":"I'm not a git developer, as I see it written on the community related page.\n\n > General questions or comments for the Git community can be sent to \nthe mailing list by using the email address git@vger.kernel.org .\n\nMy understanding is that even if it's not an advanced question about the \ndetails of development, but just a general question, it's still possible \nto discuss it on this mailing list.\n\nAt the moment my configuration file is quite short, but you mentioned \nthat the configuration files of the masters are often very long, which \nreminds me that there is a lot of room for optimization.\n\nGetting out of your comfort zone is not even an easy task, and \nunderstanding the problem clearly does require preventing expert bias, \nwhich is not easy.\n"},{"id":"426099","messageId":"YLXl5+ronWhcGh13@danh.dev","threadId":"55814","inReplyTo":"60b5d281552d6_e359f20828@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-06-01T07:47:02Z","receivedAt":"2021-06-01T07:47:09Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-06-01 01:24:01-0500, Felipe Contreras wrote:\n> Hello,\n> \n> The premise is simple: git.git developers are experts in git, and therefore\n> they have fine-tuned their ~/.gitconfig to a point that is pretty far\n> from what any newcomer will experience for a long time.\n> \n> How long can you survive with a pristine configuration?\n> \n> Plenty of developers take many things in their configuration for\n> granted, they forget what the default behavior is, or worse: they forget\n> they actually have configured log.decorate, and are surprised when they\n> discover the reason they could not reproduce a bug report.\n\nOK, the person that forgot having log.decorate configured is me.\n\n> Now and then I cleanup my configuration to be reminded of that fact.\n> \n> Anybody remembers merge.defaultToUpstream, and what `git merge` without\n> arguments used to do? [1] What about sendemail.chainReplyTo? [2]\n> \n> It's important that we force ourselves to experience what an\n> unconfigured git setup looks like, even if it's just for a little bit.\n> \n> So the challenge is this:\n> \n> 1. Remove all the configuration that is not essential (just leave\n> user.name and user.email or equivalent)\n\nHow about alias? It's part of my muscle memory.\n\n> 2. Pick 2 configurations you think you can't live without. You are not\n> allowed to change them afterwards.\n\nSomething is essential when working on constantly integration tree,\nI don't want to make my life hard:\n\n* rerere.enabled = true\n* rerere.autoupdate = true\n\nSomething is there to shut up advice, I can live without those\nconfiguration value, though (I don't use git-pull these days, anyway):\n\n* pull.rebase = false\n\nWorking with patch based need:\n\n* sendemail.smtpserver\n* sendemail.smtpencryption\n* sendemail.smtpuser\n* credential.helper\n\nMy GnuPG key is Ed25519, and gpg v2 in my machine is named gpg2, so:\n* gpg.program = gpg2\n\nAnd I would like to try new shiny features:\n\n* feature.experimental = true\n\n> 3. Every day you can add 1 additional configuration (and update it the\n> next day).\n> 4. The moment you add a 4th configuration you lose.\n\nSo, my baseline already requires 8 key-value pairs (ignoring alias and\npull.rebase). I'm lost already.\n\n-- \nDanh\n"},{"id":"426107","messageId":"60b606f029f11_e40ca20849@natae.notmuch","threadId":"55814","inReplyTo":"ea3a64bb-7c1e-465a-9639-aedeeb635d0a@gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T10:07:44Z","receivedAt":"2021-06-01T10:07:49Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andy wrote:\n> My understanding is that even if it's not an advanced question about the \n> details of development, but just a general question, it's still possible \n> to discuss it on this mailing list.\n\nYes it is.\n\n> At the moment my configuration file is quite short, but you mentioned \n> that the configuration files of the masters are often very long, which \n> reminds me that there is a lot of room for optimization.\n\nIndeed. But efen if it's short, do you need more than 2 configurations?\n(other than user.{name,email})? If so, maybe you could participate too,\nand let us know which you couldn't live without.\n\n> Getting out of your comfort zone is not even an easy task, and \n> understanding the problem clearly does require preventing expert bias, \n> which is not easy.\n\nExactly. And getting rid of our precious ~/.gitconfig (even if it's just\nfor a while) is a straightforward way to force us out.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426112","messageId":"60b61089ba63d_e40ca20894@natae.notmuch","threadId":"55814","inReplyTo":"YLXl5+ronWhcGh13@danh.dev","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T10:48:41Z","receivedAt":"2021-06-01T10:48:51Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Đoàn Trần Công Danh wrote:\n> On 2021-06-01 01:24:01-0500, Felipe Contreras wrote:\n> > The premise is simple: git.git developers are experts in git, and therefore\n> > they have fine-tuned their ~/.gitconfig to a point that is pretty far\n> > from what any newcomer will experience for a long time.\n> > \n> > How long can you survive with a pristine configuration?\n> > \n> > Plenty of developers take many things in their configuration for\n> > granted, they forget what the default behavior is, or worse: they forget\n> > they actually have configured log.decorate, and are surprised when they\n> > discover the reason they could not reproduce a bug report.\n> \n> OK, the person that forgot having log.decorate configured is me.\n\nRight. That's just the most recent instance I could think of, but I'm\nsure similar versions have happened to all of us.\n\n> > Now and then I cleanup my configuration to be reminded of that fact.\n> > \n> > Anybody remembers merge.defaultToUpstream, and what `git merge` without\n> > arguments used to do? [1] What about sendemail.chainReplyTo? [2]\n> > \n> > It's important that we force ourselves to experience what an\n> > unconfigured git setup looks like, even if it's just for a little bit.\n> > \n> > So the challenge is this:\n> > \n> > 1. Remove all the configuration that is not essential (just leave\n> > user.name and user.email or equivalent)\n> \n> How about alias? It's part of my muscle memory.\n\nNo aliases.\n\nIf a new user doesn't have them, neither should you.\n\nAll VCSs have default aliases, and I advocated for git to do the same\n[1], but it wasn't accepted.\n\nThe whole point is to suffer like them.\n\n> > 2. Pick 2 configurations you think you can't live without. You are not\n> > allowed to change them afterwards.\n> \n> Something is essential when working on constantly integration tree,\n> I don't want to make my life hard:\n> \n> * rerere.enabled = true\n> * rerere.autoupdate = true\n\nIf the defaults make your life hard, then shouldn't we change the\ndefaults?\n\nFor starters, which is the command you use? `git merge`? If so, maybe\n`git merge` should have a --rerere option to enable rerere. There are\nsome --rerere-autoupdate, but no --rerere.\n\nAdditionally, who doesn't want autoupdate when rerere is manually\nenabled?\n\nIf we all want autoupdate enabled (at least I do), maybe the default\nshould be flipped, so all you need in your configuration is:\n\n rerere.enabled = true\n\nBut, if we are already on this topic... who wants rerere disabled by\ndefault?\n\n> Something is there to shut up advice, I can live without those\n> configuration value, though (I don't use git-pull these days, anyway):\n> \n> * pull.rebase = false\n\nCan you train your fingers to type `git pull --no-rebase` for a while?\n\n> Working with patch based need:\n> \n> * sendemail.smtpserver\n> * sendemail.smtpencryption\n> * sendemail.smtpuser\n> * credential.helper\n\nYou could use msmtp instead, but fine, let's make an exception for\ntransmission of patches (credentials, SMTP, etc.) These are not options\nthat can be changed in git.gt by default.\n\nBut only the essentials, no sendemail.confirm.\n\n> My GnuPG key is Ed25519, and gpg v2 in my machine is named gpg2, so:\n> * gpg.program = gpg2\n\nYou could have an alias in your ~/bin directory:\n\n ln -s /usr/bin/gpg2 ~/bin/gpg\n\nThat way you don't need to configure every program.\n\nBut fine, this is an exception too. The location of programs is not\nsomething that can be changed by default.\n\n> And I would like to try new shiny features:\n> \n> * feature.experimental = true\n\nInteresting. I didn't know that existed, and I advocated for a\nsimilar configuration: core.mode [2].\n\nBut if most newcomers can live without it, I'm sure you can too for a\nbit.\n\n> > 3. Every day you can add 1 additional configuration (and update it the\n> > next day).\n> > 4. The moment you add a 4th configuration you lose.\n> \n> So, my baseline already requires 8 key-value pairs (ignoring alias and\n> pull.rebase). I'm lost already.\n\nWith the exceptions I think you only need these:\n\n * rerere.enabled = true\n * rerere.autoupdate = true\n\n\nBut the point is that if you can't live with git defaults, that should\ntell us something.\n\nCheers.\n\n[1] https://lore.kernel.org/git/1379791221-29925-1-git-send-email-felipe.contreras@gmail.com/\n[2] https://lore.kernel.org/git/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras"},{"id":"426115","messageId":"YLYcnwZQAEoSQKsG@danh.dev","threadId":"55814","inReplyTo":"60b61089ba63d_e40ca20894@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-06-01T11:40:15Z","receivedAt":"2021-06-01T11:40:21Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n> Đoàn Trần Công Danh wrote:\n> > On 2021-06-01 01:24:01-0500, Felipe Contreras wrote:\n> > > The premise is simple: git.git developers are experts in git, and therefore\n> > > they have fine-tuned their ~/.gitconfig to a point that is pretty far\n> > > from what any newcomer will experience for a long time.\n> > > \n> > > How long can you survive with a pristine configuration?\n> > > \n> > > Plenty of developers take many things in their configuration for\n> > > granted, they forget what the default behavior is, or worse: they forget\n> > > they actually have configured log.decorate, and are surprised when they\n> > > discover the reason they could not reproduce a bug report.\n> > \n> > OK, the person that forgot having log.decorate configured is me.\n> \n> Right. That's just the most recent instance I could think of, but I'm\n> sure similar versions have happened to all of us.\n> \n> > > Now and then I cleanup my configuration to be reminded of that fact.\n> > > \n> > > Anybody remembers merge.defaultToUpstream, and what `git merge` without\n> > > arguments used to do? [1] What about sendemail.chainReplyTo? [2]\n> > > \n> > > It's important that we force ourselves to experience what an\n> > > unconfigured git setup looks like, even if it's just for a little bit.\n> > > \n> > > So the challenge is this:\n> > > \n> > > 1. Remove all the configuration that is not essential (just leave\n> > > user.name and user.email or equivalent)\n> > \n> > How about alias? It's part of my muscle memory.\n> \n> No aliases.\n> \n> If a new user doesn't have them, neither should you.\n> \n> All VCSs have default aliases, and I advocated for git to do the same\n> [1], but it wasn't accepted.\n> \n> The whole point is to suffer like them.\n\nOK.\n\n> \n> > > 2. Pick 2 configurations you think you can't live without. You are not\n> > > allowed to change them afterwards.\n> > \n> > Something is essential when working on constantly integration tree,\n> > I don't want to make my life hard:\n> > \n> > * rerere.enabled = true\n> > * rerere.autoupdate = true\n> \n> If the defaults make your life hard, then shouldn't we change the\n> defaults?\n> \n> For starters, which is the command you use? `git merge`? If so, maybe\n> `git merge` should have a --rerere option to enable rerere. There are\n> some --rerere-autoupdate, but no --rerere.\n\nI think both pull, merge, rebase, cherry-pick, revert, checkout,\nswitch, apply, am will be affected by rerere.\n\n> Additionally, who doesn't want autoupdate when rerere is manually\n> enabled?\n\nDun know. I guess someone applies other people patches\nwith their rerere logs.\n\n> If we all want autoupdate enabled (at least I do), maybe the default\n> should be flipped, so all you need in your configuration is:\n> \n> rerere.enabled = true\n> \n> But, if we are already on this topic... who wants rerere disabled by\n> default?\n> \n> > Something is there to shut up advice, I can live without those\n> > configuration value, though (I don't use git-pull these days, anyway):\n> > \n> > * pull.rebase = false\n> \n> Can you train your fingers to type `git pull --no-rebase` for a while?\n\nI don't use git-pull nowaday, so, I don't care.\n\n> \n> > Working with patch based need:\n> > \n> > * sendemail.smtpserver\n> > * sendemail.smtpencryption\n> > * sendemail.smtpuser\n> > * credential.helper\n> \n> You could use msmtp instead, but fine, let's make an exception for\n> transmission of patches (credentials, SMTP, etc.) These are not options\n> that can be changed in git.gt by default.\n> \n> But only the essentials, no sendemail.confirm.\n> \n> > My GnuPG key is Ed25519, and gpg v2 in my machine is named gpg2, so:\n> > * gpg.program = gpg2\n> \n> You could have an alias in your ~/bin directory:\n> \n> ln -s /usr/bin/gpg2 ~/bin/gpg\n> \n> That way you don't need to configure every program.\n\nFair!\n\n> But fine, this is an exception too. The location of programs is not\n> something that can be changed by default.\n> \n> > And I would like to try new shiny features:\n> > \n> > * feature.experimental = true\n> \n> Interesting. I didn't know that existed, and I advocated for a\n> similar configuration: core.mode [2].\n> \n> But if most newcomers can live without it, I'm sure you can too for a\n> bit.\n\nThe point of trying new shiny features is dogfooding ourselves and\nreport bugs early, if any.\n\n> > > 3. Every day you can add 1 additional configuration (and update it the\n> > > next day).\n> > > 4. The moment you add a 4th configuration you lose.\n> > \n> > So, my baseline already requires 8 key-value pairs (ignoring alias and\n> > pull.rebase). I'm lost already.\n> \n> With the exceptions I think you only need these:\n> \n> * rerere.enabled = true\n> * rerere.autoupdate = true\n\nOK, let's start there.\n\n-- \nDanh\n"},{"id":"426118","messageId":"60b62665df1de_e40952080@natae.notmuch","threadId":"55814","inReplyTo":"YLYcnwZQAEoSQKsG@danh.dev","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T12:21:57Z","receivedAt":"2021-06-01T12:22:02Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Đoàn Trần Công Danh wrote:\n> On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n> > Đoàn Trần Công Danh wrote:\n> > > Something is essential when working on constantly integration tree,\n> > > I don't want to make my life hard:\n> > > \n> > > * rerere.enabled = true\n> > > * rerere.autoupdate = true\n> > \n> > If the defaults make your life hard, then shouldn't we change the\n> > defaults?\n> > \n> > For starters, which is the command you use? `git merge`? If so, maybe\n> > `git merge` should have a --rerere option to enable rerere. There are\n> > some --rerere-autoupdate, but no --rerere.\n> \n> I think both pull, merge, rebase, cherry-pick, revert, checkout,\n> switch, apply, am will be affected by rerere.\n\nYes, I know, but I am talking about you personally. Where do you\nabsolutely need --rerere?\n\n> > But fine, this is an exception too. The location of programs is not\n> > something that can be changed by default.\n> > \n> > > And I would like to try new shiny features:\n> > > \n> > > * feature.experimental = true\n> > \n> > Interesting. I didn't know that existed, and I advocated for a\n> > similar configuration: core.mode [2].\n> > \n> > But if most newcomers can live without it, I'm sure you can too for a\n> > bit.\n> \n> The point of trying new shiny features is dogfooding ourselves and\n> report bugs early, if any.\n\nYes, and more developers should turn this flag on, but it's not\n*essential*, so you can live one month with it off. Either way I don't\nthink it matters for the purpose of this experiment if you have it or\nnot.\n\n> > > > 3. Every day you can add 1 additional configuration (and update it the\n> > > > next day).\n> > > > 4. The moment you add a 4th configuration you lose.\n> > > \n> > > So, my baseline already requires 8 key-value pairs (ignoring alias and\n> > > pull.rebase). I'm lost already.\n> > \n> > With the exceptions I think you only need these:\n> > \n> > * rerere.enabled = true\n> > * rerere.autoupdate = true\n> \n> OK, let's start there.\n\nExcellent.\n\n-- \nFelipe Contreras"},{"id":"426119","messageId":"YLYn7iMA+Ne8nbJk@danh.dev","threadId":"55814","inReplyTo":"60b62665df1de_e40952080@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-06-01T12:28:30Z","receivedAt":"2021-06-01T12:28:36Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-06-01 07:21:57-0500, Felipe Contreras wrote:\n> Đoàn Trần Công Danh wrote:\n> > On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n> > > Đoàn Trần Công Danh wrote:\n> > > > Something is essential when working on constantly integration tree,\n> > > > I don't want to make my life hard:\n> > > > \n> > > > * rerere.enabled = true\n> > > > * rerere.autoupdate = true\n> > > \n> > > If the defaults make your life hard, then shouldn't we change the\n> > > defaults?\n> > > \n> > > For starters, which is the command you use? `git merge`? If so, maybe\n> > > `git merge` should have a --rerere option to enable rerere. There are\n> > > some --rerere-autoupdate, but no --rerere.\n> > \n> > I think both pull, merge, rebase, cherry-pick, revert, checkout,\n> > switch, apply, am will be affected by rerere.\n> \n> Yes, I know, but I am talking about you personally. Where do you\n> absolutely need --rerere?\n\nI need rerere in both of merge, rebase, cherry-pick, revert, switch, am\nDon't ask me why, I use all of them in a daily basis. And rerere saves\nme a lot of trouble.\n\nI don't use git-pull nowaday. But, should I use git-pull,\nI'll need rerere there, too (it's a fetch followed by merge/rebase,\nanyway).\n\n-- Danh\n\n> > > But fine, this is an exception too. The location of programs is not\n> > > something that can be changed by default.\n> > > \n> > > > And I would like to try new shiny features:\n> > > > \n> > > > * feature.experimental = true\n> > > \n> > > Interesting. I didn't know that existed, and I advocated for a\n> > > similar configuration: core.mode [2].\n> > > \n> > > But if most newcomers can live without it, I'm sure you can too for a\n> > > bit.\n> > \n> > The point of trying new shiny features is dogfooding ourselves and\n> > report bugs early, if any.\n> \n> Yes, and more developers should turn this flag on, but it's not\n> *essential*, so you can live one month with it off. Either way I don't\n> think it matters for the purpose of this experiment if you have it or\n> not.\n> \n> > > > > 3. Every day you can add 1 additional configuration (and update it the\n> > > > > next day).\n> > > > > 4. The moment you add a 4th configuration you lose.\n> > > > \n> > > > So, my baseline already requires 8 key-value pairs (ignoring alias and\n> > > > pull.rebase). I'm lost already.\n> > > \n> > > With the exceptions I think you only need these:\n> > > \n> > > * rerere.enabled = true\n> > > * rerere.autoupdate = true\n> > \n> > OK, let's start there.\n> \n> Excellent.\n> \n> -- \n> Felipe Contreras\n\n-- \nDanh\n"},{"id":"426121","messageId":"60b632a3d5a2c_e5b8b20876@natae.notmuch","threadId":"55814","inReplyTo":"YLYn7iMA+Ne8nbJk@danh.dev","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T13:14:11Z","receivedAt":"2021-06-01T13:14:16Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Đoàn Trần Công Danh wrote:\n> On 2021-06-01 07:21:57-0500, Felipe Contreras wrote:\n> > Yes, I know, but I am talking about you personally. Where do you\n> > absolutely need --rerere?\n> \n> I need rerere in both of merge, rebase, cherry-pick, revert, switch, am\n> Don't ask me why, I use all of them in a daily basis. And rerere saves\n> me a lot of trouble.\n\nFair enough. If you need it you need it.\n\nBut probably many users would benefit from rerere too, and they don't\neven realize it exists.\n\nBTW. I've done integrations too, and I understand perfectly why you need\nit.\n\nCheers.\n\nhttps://github.com/felipec/git-reintegrate\n\n-- \nFelipe Contreras"},{"id":"426169","messageId":"CAJDDKr7AG_qs2ZmNCuS9zS0oqCT9cWU=CSCfxALEkGuLHBH=OQ@mail.gmail.com","threadId":"55814","inReplyTo":"60b5d281552d6_e359f20828@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2021-06-01T21:56:48Z","receivedAt":"2021-06-01T21:57:28Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, May 31, 2021 at 11:26 PM Felipe Contreras\n wrote:\n> So the challenge is this:\n>\n> 1. Remove all the configuration that is not essential (just leave\n> user.name and user.email or equivalent)\n> 2. Pick 2 configurations you think you can't live without. You are not\n> allowed to change them afterwards.\n> 3. Every day you can add 1 additional configuration (and update it the\n> next day).\n> 4. The moment you add a 4th configuration you lose.\n>\n> Once you've lost, reply to this message with the configuration you could\n> not live without.\n\n+1 for merge.conflictstyle = diff3, rerere.enabled = true, and\nlog.decorate = short from me. I noticed others already mentioned\nthese.\n\nMy favorites which no one has mentioned yet are rebase.autosquash =\ntrue and rebase.autostash = true. IMO these two really improve\nrebase's usability.\n\ncheers,\n-- \nDavid\n"},{"id":"426171","messageId":"xmqqzgw9qky5.fsf@gitster.g","threadId":"55814","inReplyTo":"CAJDDKr7AG_qs2ZmNCuS9zS0oqCT9cWU=CSCfxALEkGuLHBH=OQ@mail.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-01T22:28:02Z","receivedAt":"2021-06-01T22:28:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and\n> log.decorate = short from me. I noticed others already mentioned\n> these.\n\nAs the inventor of rerere, I agree on rerere.enabled. It was made\nopt-in only because I thought it was somewhat risky when the feature\nwas introduced, but it has been stable and useful, and it is long\noverdue to be enabled by default.\n\nI do not think of any downside with conflictstyle being diff3 (and\nthink of only upside). As to log.decorate, I see it as mostly\npersonal preference and the current default of \"auto\" seems more\nappropriate.\n"},{"id":"426172","messageId":"87wnrd6wqj.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"60b5d281552d6_e359f20828@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-01T22:33:40Z","receivedAt":"2021-06-01T22:33:46Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Felipe Contreras writes:\n\n> Hello,\n>\n\n[...]\n\n> These are the configurations I've chosen:\n>\n> [merge]\n> conflictstyle = diff3\n> [sendemail]\n> smtpserver = /usr/bin/msmtp\n>\n\n[pull]\n\trebase = merges\n[push]\n\tdefault = simple\n[rerere]\n\tenabled = true\n\tautoupdate = true\n[diff]\n\talgorithm = patience\n[merge]\n conflictStyle = diff3\n\n-- Sergey Organov\n"},{"id":"426173","messageId":"xmqqv96xqjyr.fsf@gitster.g","threadId":"55814","inReplyTo":"xmqqzgw9qky5.fsf@gitster.g","subject":"Re: The git spring cleanup challenge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-01T22:49:16Z","receivedAt":"2021-06-01T22:49:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> David Aguilar writes:\n>\n>> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and\n>> log.decorate = short from me. I noticed others already mentioned\n>> these.\n>\n> As the inventor of rerere, I agree on rerere.enabled. It was made\n> opt-in only because I thought it was somewhat risky when the feature\n> was introduced, but it has been stable and useful, and it is long\n> overdue to be enabled by default.\n\nJust to make sure, rerere.enabled is fine, but as I am not\ncomfortable to recommend rerere.autoupdate to any human users, I\nwould be opposed to turning it on by default. Giving people a\nchoice is fine, but the default should be a safe one that offers\nusers a chance of final sanity checking before proceeding.\n"},{"id":"426174","messageId":"60b6bef41791a_404420881@natae.notmuch","threadId":"55814","inReplyTo":"xmqqzgw9qky5.fsf@gitster.g","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T23:12:52Z","receivedAt":"2021-06-01T23:12:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> David Aguilar writes:\n> \n> > +1 for merge.conflictstyle = diff3, rerere.enabled = true, and\n> > log.decorate = short from me. I noticed others already mentioned\n> > these.\n> \n> As the inventor of rerere, I agree on rerere.enabled. It was made\n> opt-in only because I thought it was somewhat risky when the feature\n> was introduced, but it has been stable and useful, and it is long\n> overdue to be enabled by default.\n\nAgreed.\n\nI personally would like some interface to see what's going on behind the\nscenes because sometimes I've made a wrong resolution that gets carried\naround and I don't know of a way to clear them (other than manually\nhunting down the cached files).\n\nBut this is not a deal-breaker, the feature works great.\n\n> I do not think of any downside with conflictstyle being diff3 (and\n> think of only upside).\n\nSame here.\n\nI recall reading about issues of a GSoC student resolving conflicts and\nsetting up a mergetool. And he (or she?) mentioned the advice to\nconfigure diff3... I didn't even remember there was anything else.\n\nI wrote vimdiff3 precisely to edit diff3 output directly, and I've never\nlooked back.\n\n-- \nFelipe Contreras\n"},{"id":"426175","messageId":"60b6c08f75c1c_40442086d@natae.notmuch","threadId":"55814","inReplyTo":"87wnrd6wqj.fsf@osv.gnss.ru","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T23:19:43Z","receivedAt":"2021-06-01T23:19:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sergey Organov wrote:\n> Felipe Contreras writes:\n\n> > These are the configurations I've chosen:\n> >\n> > [merge]\n> > conflictstyle = diff3\n> > [sendemail]\n> > smtpserver = /usr/bin/msmtp\n> >\n> \n> [pull]\n> \trebase = merges\n\nCan you do `git pull --rebase=merges` for a while?\n\n> [push]\n> \tdefault = simple\n\nThis is the default, you don't need it.\n\n> [rerere]\n> \tenabled = true\n> \tautoupdate = true\n\nWe are seeing a pattern here.\n\n> [diff]\n> \talgorithm = patience\n\nDoes this make a lot of difference?\n\n> [merge]\n> conflictStyle = diff3\n\nSame here.\n\n-- \nFelipe Contreras\n"},{"id":"426178","messageId":"60b6c642ba65b_4044208ca@natae.notmuch","threadId":"55814","inReplyTo":"xmqqv96xqjyr.fsf@gitster.g","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-01T23:44:02Z","receivedAt":"2021-06-01T23:44:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Junio C Hamano writes:\n> > David Aguilar writes:\n\n> >> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and\n> >> log.decorate = short from me. I noticed others already mentioned\n> >> these.\n> >\n> > As the inventor of rerere, I agree on rerere.enabled. It was made\n> > opt-in only because I thought it was somewhat risky when the feature\n> > was introduced, but it has been stable and useful, and it is long\n> > overdue to be enabled by default.\n> \n> Just to make sure, rerere.enabled is fine, but as I am not\n> comfortable to recommend rerere.autoupdate to any human users, I\n> would be opposed to turning it on by default. Giving people a\n> choice is fine, but the default should be a safe one that offers\n> users a chance of final sanity checking before proceeding.\n\nNo commit is made. Doesn't `git diff --staged` offer users such chance?\n\n-- \nFelipe Contreras\n"},{"id":"426191","messageId":"8f8d023a-936a-948f-7b36-655774319ba9@gmail.com","threadId":"55814","inReplyTo":"60b5d281552d6_e359f20828@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-06-02T03:43:07Z","receivedAt":"2021-06-02T03:43:21Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"Hi Felipe, sorry for responding in long time.\n\nOn 01/06/21 13.24, Felipe Contreras wrote:\n> Once you've lost, reply to this message with the configuration you could\n> not live without.\n> \n\nI'm not opting in into the challenge, but here are my mandatory global \nconfigurations:\n\n> [core]\n> editor = rvim\n\nI set core.editor to rvim because of my habit to edit using restricted \nvim (as I only use vim to edit files, nothing else).\n\n> [merge]\n> conflictstyle = diff3\n\nWith diff3 conflict style, I can clearly see the context of conflict \n(base) instead of having to choose between either side without context.\n\nFor several repos, I do GPG-sign commits, so the required config is:\n\n> [user]\n> signingkey = \n\nOn very large repos I have (for example GCC and Linux kernel), I have:\n\n> [pack]\n> packSizeLimit = 650m\n> windowMemory = 400m\n\nBoth pack.packSizeLimit and pack.windowMemory helps when doing \ngit-repack there. With the former, the resulting pack file is limited to \n650M size each, and the latter set memory window during delta compression.\n\nThanks.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"426192","messageId":"60b70209342d1_511920812@natae.notmuch","threadId":"55814","inReplyTo":"8f8d023a-936a-948f-7b36-655774319ba9@gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-02T03:59:05Z","receivedAt":"2021-06-02T04:01:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Bagas Sanjaya wrote:\n> On 01/06/21 13.24, Felipe Contreras wrote:\n> > Once you've lost, reply to this message with the configuration you could\n> > not live without.\n> > \n> \n> I'm not opting in into the challenge, but here are my mandatory global \n> configurations:\n> \n> > [core]\n> > editor = rvim\n> \n> I set core.editor to rvim because of my habit to edit using restricted \n> vim (as I only use vim to edit files, nothing else).\n\nWhy not VISUAL=rvim? (or EDITOR)\n\n> > [merge]\n> > conflictstyle = diff3\n> \n> With diff3 conflict style, I can clearly see the context of conflict \n> (base) instead of having to choose between either side without context.\n> \n> For several repos, I do GPG-sign commits, so the required config is:\n\nYeap, just like apparently everyone else.\n\n> On very large repos I have (for example GCC and Linux kernel), I have:\n> \n> > [pack]\n> > packSizeLimit = 650m\n> > windowMemory = 400m\n> \n> Both pack.packSizeLimit and pack.windowMemory helps when doing \n> git-repack there. With the former, the resulting pack file is limited to \n> 650M size each, and the latter set memory window during delta compression.\n\nAll right. But I presume you don't need to do `git repack` that often.\nYou can wait a month, or type --max-pack-size --window-memory if you\nreally must run it.\n\nEither way it's probably not some defaults that newcomers would benefit\nfrom.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426194","messageId":"YLcFU+ORZTzAsyBy@danh.dev","threadId":"55814","inReplyTo":"60b61089ba63d_e40ca20894@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-06-02T04:13:07Z","receivedAt":"2021-06-02T04:13:13Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n> > How about alias? It's part of my muscle memory.\n> \n> No aliases.\n> \n> If a new user doesn't have them, neither should you.\n> \n> All VCSs have default aliases, and I advocated for git to do the same\n> [1], but it wasn't accepted.\n> \n> The whole point is to suffer like them.\n\nGet back to the alias topic.\nI also agree with other people's opinion in that thread.\nIOW, I support the decision to not accept those default alias ;)\n\nIt's not required to be different people to have alias defined to\ndifferent command. I have alias conditionally defined to different\ncommand based on git-dir. For example, I had ci alias to \"commit\" by\ndefault, and \"commit -s\" on other repositories.\n\nSo, Git decides alias for me will not only break my current alias, but\nalso break my conditional alias.\n\nAnyway, remotes/branches are all configuration values.\nWould you prefer:\n\n\tgit remote add a-remote git://some/repository.git\n\tgit fetch a-remote a-branch && git merge FETCH_HEAD\n\nor\n\tgit fetch git://some/repository.git a-branch && git merge FETCH_HEAD\n\nI guess it's another exception, then ;)\n\n> [1] https://lore.kernel.org/git/1379791221-29925-1-git-send-email-felipe.contreras@gmail.com/\n\n-- \nDanh\n"},{"id":"426195","messageId":"60b70eb930614_4abd208ad@natae.notmuch","threadId":"55814","inReplyTo":"YLcFU+ORZTzAsyBy@danh.dev","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-02T04:53:13Z","receivedAt":"2021-06-02T04:53:18Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Đoàn Trần Công Danh wrote:\n> On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n> > > How about alias? It's part of my muscle memory.\n> > \n> > No aliases.\n> > \n> > If a new user doesn't have them, neither should you.\n> > \n> > All VCSs have default aliases, and I advocated for git to do the same\n> > [1], but it wasn't accepted.\n> > \n> > The whole point is to suffer like them.\n> \n> Get back to the alias topic.\n> I also agree with other people's opinion in that thread.\n> IOW, I support the decision to not accept those default alias ;)\n\nWhy?\n\n> It's not required to be different people to have alias defined to\n> different command. I have alias conditionally defined to different\n> command based on git-dir. For example, I had ci alias to \"commit\" by\n> default, and \"commit -s\" on other repositories.\n\nSo? They would still work.\n\n> So, Git decides alias for me will not only break my current alias, but\n> also break my conditional alias.\n\nNo it wouldn't. They are *default* aliases, not overriding aliases. They\nwould be used only if you haven't set the same alias yourself.\n\nTry it.\n\n--- a/alias.c\n+++ b/alias.c\n@@ -28,13 +28,27 @@ static int config_alias_cb(const char *key, const char *value, void *d)\n return 0;\n }\n \n+struct config_alias_data default_aliases[] = {\n+ { \"co\", \"checkout\" },\n+ { \"ci\", \"checkout\" },\n+ { \"rb\", \"rebase\" },\n+ { \"st\", \"status\" },\n+};\n+\n char *alias_lookup(const char *alias)\n {\n struct config_alias_data data = { alias, NULL };\n+ int i;\n \n read_early_config(config_alias_cb, &data);\n+ if (data.v)\n+ return data.v;\n+ for (i = 0; i < ARRAY_SIZE(default_aliases); i++) {\n+ if (!strcmp(alias, default_aliases[i].alias))\n+ return xstrdup(default_aliases[i].v);\n+ }\n \n- return data.v;\n+ return NULL;\n }\n \n void list_aliases(struct string_list *list)\n\n\n> Anyway, remotes/branches are all configuration values.\n> Would you prefer:\n\nI meant global configurations. If it's a per-repository setting surely\nit wouldn't be something amenable for the Git project to set as default.\n\n-- \nFelipe Contreras"},{"id":"426202","messageId":"9fb1f823-44f8-8046-adb5-d2c0fdb6b5a0@kdbg.org","threadId":"55814","inReplyTo":"60b6c642ba65b_4044208ca@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2021-06-02T06:47:01Z","receivedAt":"2021-06-02T06:47:11Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 02.06.21 um 01:44 schrieb Felipe Contreras:\n> Junio C Hamano wrote:\n>> Junio C Hamano writes:\n>>> David Aguilar writes:\n> \n>>>> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and\n>>>> log.decorate = short from me. I noticed others already mentioned\n>>>> these.\n\nDoes diff3 conflict style reduce conflicts to their minimum? I don't\nthink so. Therefore, a strong -1 for this as the default.\n\n>>> As the inventor of rerere, I agree on rerere.enabled. It was made\n>>> opt-in only because I thought it was somewhat risky when the feature\n>>> was introduced, but it has been stable and useful, and it is long\n>>> overdue to be enabled by default.\n>>\n>> Just to make sure, rerere.enabled is fine, but as I am not\n>> comfortable to recommend rerere.autoupdate to any human users, I\n>> would be opposed to turning it on by default. Giving people a\n>> choice is fine, but the default should be a safe one that offers\n>> users a chance of final sanity checking before proceeding.\n> \n> No commit is made. Doesn't `git diff --staged` offer users such chance?\n\nrerere.autoupdate erases the information which files had conflicts. In\nmy workflow, the rerere database time and again does hold outdated merge\nresolutions. I want to have an opportunity to cross-check the automatic\nresolutions, and for that I need to know which files had conflicts.\n\nI'm using a toolset on top of Git and am not paying attention to the\nterminal---if and when I'm using it at all---that would list the\nconflicted files. So, I'm strongly opposed to enabling it by default.\n\nBTW, a +1 for rerere.enabled=true from me.\n\n-- Hannes\n"},{"id":"426203","messageId":"60b72ad0ccc57_501332083f@natae.notmuch","threadId":"55814","inReplyTo":"9fb1f823-44f8-8046-adb5-d2c0fdb6b5a0@kdbg.org","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-02T06:53:04Z","receivedAt":"2021-06-02T06:53:09Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Johannes Sixt wrote:\n> Am 02.06.21 um 01:44 schrieb Felipe Contreras:\n> > Junio C Hamano wrote:\n> >> Junio C Hamano writes:\n> >>> David Aguilar writes:\n> > \n> >>>> +1 for merge.conflictstyle = diff3, rerere.enabled = true, and\n> >>>> log.decorate = short from me. I noticed others already mentioned\n> >>>> these.\n> \n> Does diff3 conflict style reduce conflicts to their minimum?\n\nThe objective is to resolve conflicts, not to see minimum conflicts.\n\n> >>> As the inventor of rerere, I agree on rerere.enabled. It was made\n> >>> opt-in only because I thought it was somewhat risky when the feature\n> >>> was introduced, but it has been stable and useful, and it is long\n> >>> overdue to be enabled by default.\n> >>\n> >> Just to make sure, rerere.enabled is fine, but as I am not\n> >> comfortable to recommend rerere.autoupdate to any human users, I\n> >> would be opposed to turning it on by default. Giving people a\n> >> choice is fine, but the default should be a safe one that offers\n> >> users a chance of final sanity checking before proceeding.\n> > \n> > No commit is made. Doesn't `git diff --staged` offer users such chance?\n> \n> rerere.autoupdate erases the information which files had conflicts. In\n> my workflow, the rerere database time and again does hold outdated merge\n> resolutions. I want to have an opportunity to cross-check the automatic\n> resolutions, and for that I need to know which files had conflicts.\n\nThen do rerere.autoupdate=false.\n\nDefaults are not for you, they are for the majority of users.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426217","messageId":"xmqqo8co7cqe.fsf@gitster.g","threadId":"55814","inReplyTo":"9fb1f823-44f8-8046-adb5-d2c0fdb6b5a0@kdbg.org","subject":"Re: The git spring cleanup challenge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-02T11:00:25Z","receivedAt":"2021-06-02T11:00:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> rerere.autoupdate erases the information which files had conflicts.\n> ... So, I'm strongly opposed to enabling it by default.\n\nExactly. \"checkout -m\" can use resolve-undo information to\nunresolve the conflicts, but to make effective use of it, you'd want\nto know which paths had conflicts to begin with.\n"},{"id":"426223","messageId":"60b76a804d652_15ec5620819@natae.notmuch","threadId":"55814","inReplyTo":"xmqqo8co7cqe.fsf@gitster.g","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-02T11:24:48Z","receivedAt":"2021-06-02T11:25:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Johannes Sixt writes:\n> \n> > rerere.autoupdate erases the information which files had conflicts.\n> > ... So, I'm strongly opposed to enabling it by default.\n> \n> Exactly. \"checkout -m\" can use resolve-undo information to\n> unresolve the conflicts, but to make effective use of it, you'd want\n> to know which paths had conflicts to begin with.\n\nWho is \"you\" in this case?\n\nIs it the typical git user?\n\n-- \nFelipe Contreras\n"},{"id":"426227","messageId":"YLdvJ0G19LNcbDSD@danh.dev","threadId":"55814","inReplyTo":"xmqqo8co7cqe.fsf@gitster.g","subject":"Re: The git spring cleanup challenge","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-06-02T11:44:39Z","receivedAt":"2021-06-02T11:44:48Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-06-02 20:00:25+0900, Junio C Hamano wrote:\n> Johannes Sixt writes:\n> \n> > rerere.autoupdate erases the information which files had conflicts.\n> > ... So, I'm strongly opposed to enabling it by default.\n> \n> Exactly. \"checkout -m\" can use resolve-undo information to\n> unresolve the conflicts, but to make effective use of it, you'd want\n> to know which paths had conflicts to begin with.\n\nI don't know about this one. I had been bitten by rerere.autoupdate\nsometimes. And I need to wipe out the rerere record to start over.\n\nI guess I should turn it off, then.\n\n-- \nDanh\n"},{"id":"426231","messageId":"87im2wtqg2.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"60b6bef41791a_404420881@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-02T12:13:17Z","receivedAt":"2021-06-02T12:13:39Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> David Aguilar writes:\n>> \n>> > +1 for merge.conflictstyle = diff3, rerere.enabled = true, and\n>> > log.decorate = short from me. I noticed others already mentioned\n>> > these.\n>> \n>> As the inventor of rerere, I agree on rerere.enabled. It was made\n>> opt-in only because I thought it was somewhat risky when the feature\n>> was introduced, but it has been stable and useful, and it is long\n>> overdue to be enabled by default.\n>\n> Agreed.\n>\n> I personally would like some interface to see what's going on behind the\n> scenes because sometimes I've made a wrong resolution that gets carried\n> around and I don't know of a way to clear them (other than manually\n> hunting down the cached files).\n\nI'm second here. Wanted to get rid of some recorded resolutions, but\ndidn't find a suitable way to.\n\nThanks,\n-- Sergey Organov.\n"},{"id":"426232","messageId":"87eedktq4x.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"60b6c08f75c1c_40442086d@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-02T12:19:58Z","receivedAt":"2021-06-02T12:20:04Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Felipe Contreras writes:\n\n> Sergey Organov wrote:\n>> Felipe Contreras writes:\n>\n>> > These are the configurations I've chosen:\n>> >\n>> > [merge]\n>> > conflictstyle = diff3\n>> > [sendemail]\n>> > smtpserver = /usr/bin/msmtp\n>> >\n>> \n>> [pull]\n>> \trebase = merges\n>\n> Can you do `git pull --rebase=merges` for a while?\n\nI never use 'git pull' for merging, and all the time with rebasing, so\nwhat's the point? I mean, whenever I do 'git pull' I mean 'git pull\n--rebase', and whenever I need to merge, I exclusively use'git merge'.\n\n>\n>> [push]\n>> \tdefault = simple\n>\n> This is the default, you don't need it.\n\nYep, a remnant from the past.\n\n>\n>> [rerere]\n>> \tenabled = true\n>> \tautoupdate = true\n>\n> We are seeing a pattern here.\n>\n>> [diff]\n>> \talgorithm = patience\n>\n> Does this make a lot of difference?\n\nAs far as I recall, I had some mismerges long time ago that this setting\naffected positively, so I've tweaked it.\n\nThanks,\n-- Sergey Organov\n"},{"id":"426246","messageId":"f2b0c200-ff4f-da5e-ff49-c440ff0813de@kdbg.org","threadId":"55814","inReplyTo":"YLdvJ0G19LNcbDSD@danh.dev","subject":"Re: The git spring cleanup challenge","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2021-06-02T18:13:13Z","receivedAt":"2021-06-02T18:13:18Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 02.06.21 um 13:44 schrieb Đoàn Trần Công Danh:\n> On 2021-06-02 20:00:25+0900, Junio C Hamano wrote:\n>> Johannes Sixt writes:\n>>\n>>> rerere.autoupdate erases the information which files had conflicts.\n>>> ... So, I'm strongly opposed to enabling it by default.\n>>\n>> Exactly. \"checkout -m\" can use resolve-undo information to\n>> unresolve the conflicts, but to make effective use of it, you'd want\n>> to know which paths had conflicts to begin with.\n> \n> I don't know about this one. I had been bitten by rerere.autoupdate\n> sometimes. And I need to wipe out the rerere record to start over.\n> \n> I guess I should turn it off, then.\n\nYou can use\n\n git rerere forget that/file\n\nto erase the record for the current resolution of that/file. Then you\ncan recreate the conflict using\n\n git checkout -m -- that/file\n\nIt may be necessary to run\n\n git rerere\n\nat this point to save the pre-image of the conflict record, but I'm not\nsure.\n\n-- Hannes\n"},{"id":"426267","messageId":"60b7f7e03fc64_16925f208d4@natae.notmuch","threadId":"55814","inReplyTo":"87eedktq4x.fsf@osv.gnss.ru","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-02T21:28:00Z","receivedAt":"2021-06-02T21:28:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sergey Organov wrote:\n> Felipe Contreras writes:\n> \n> > Sergey Organov wrote:\n> >> Felipe Contreras writes:\n> >\n> >> > These are the configurations I've chosen:\n> >> >\n> >> > [merge]\n> >> > conflictstyle = diff3\n> >> > [sendemail]\n> >> > smtpserver = /usr/bin/msmtp\n> >> >\n> >> \n> >> [pull]\n> >> \trebase = merges\n> >\n> > Can you do `git pull --rebase=merges` for a while?\n> \n> I never use 'git pull' for merging, and all the time with rebasing, so\n> what's the point? I mean, whenever I do 'git pull' I mean 'git pull\n> --rebase', and whenever I need to merge, I exclusively use'git merge'.\n\nSo you can remove that configuration.\n\nAnd afterwareds set pull.rebase=true so you don't need to specify\n--rebase.\n\n> >> [rerere]\n> >> \tenabled = true\n> >> \tautoupdate = true\n> >\n> > We are seeing a pattern here.\n> >\n> >> [diff]\n> >> \talgorithm = patience\n> >\n> > Does this make a lot of difference?\n> \n> As far as I recall, I had some mismerges long time ago that this setting\n> affected positively, so I've tweaked it.\n\nTry running without it for a while. If you see issues then parhaps it's\nan indication that patience is a better default algorithm.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426268","messageId":"8735tzncr0.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"60b7f7e03fc64_16925f208d4@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-02T22:05:39Z","receivedAt":"2021-06-02T22:06:59Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Felipe Contreras writes:\n\n> Sergey Organov wrote:\n>> Felipe Contreras writes:\n>> \n>> > Sergey Organov wrote:\n>> >> Felipe Contreras writes:\n>> >\n>> >> > These are the configurations I've chosen:\n>> >> >\n>> >> > [merge]\n>> >> > conflictstyle = diff3\n>> >> > [sendemail]\n>> >> > smtpserver = /usr/bin/msmtp\n>> >> >\n>> >> \n>> >> [pull]\n>> >> \trebase = merges\n>> >\n>> > Can you do `git pull --rebase=merges` for a while?\n>> \n>> I never use 'git pull' for merging, and all the time with rebasing, so\n>> what's the point? I mean, whenever I do 'git pull' I mean 'git pull\n>> --rebase', and whenever I need to merge, I exclusively use'git merge'.\n>\n> So you can remove that configuration.\n\nSorry, I can't, see below.\n\n>\n> And afterwareds set pull.rebase=true so you don't need to specify\n> --rebase.\n\nI don't get it. What's the point using pull.rebase=true instead of\npull.rebase=merges? The former is plain total disaster in my opinion as\nit silently breaks history shape. I'd rather suggest to make\npull.rebase=true a synonym for pull.rebase=merges.\n\nThanks,\n-- Sergey Organov\n"},{"id":"426270","messageId":"60b80752a4c08_16dbed20839@natae.notmuch","threadId":"55814","inReplyTo":"8735tzncr0.fsf@osv.gnss.ru","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-02T22:33:54Z","receivedAt":"2021-06-02T22:34:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Sergey Organov wrote:\n> Felipe Contreras writes:\n> > Sergey Organov wrote:\n> >> Felipe Contreras writes:\n> >> > Sergey Organov wrote:\n\n> >> >> [pull]\n> >> >> \trebase = merges\n> >> >\n> >> > Can you do `git pull --rebase=merges` for a while?\n> >> \n> >> I never use 'git pull' for merging, and all the time with rebasing, so\n> >> what's the point? I mean, whenever I do 'git pull' I mean 'git pull\n> >> --rebase', and whenever I need to merge, I exclusively use'git merge'.\n> >\n> > So you can remove that configuration.\n> \n> Sorry, I can't, see below.\n> \n> > And afterwareds set pull.rebase=true so you don't need to specify\n> > --rebase.\n> \n> I don't get it. What's the point using pull.rebase=true instead of\n> pull.rebase=merges? The former is plain total disaster in my opinion as\n> it silently breaks history shape.\n\nI think there's some confusion here.\n\nYou said you always did `git pull --rebase`, not\n`git pull --rebase=merges`.\n\nThe equivalent configurations are:\n\n git pull --rebase\t\t=> pull.rebase=true\n git pull --rebase=merges\t=> pull.rebase=merges\n\nIf you can't live without the functionality `pull.rebase=merges` gives\nyou, that means you have to type `git pull --rebase=merges` if you don't\nhave such configuration.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426272","messageId":"877djbkgoi.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"60b80752a4c08_16dbed20839@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-02T23:09:01Z","receivedAt":"2021-06-02T23:10:05Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Felipe Contreras writes:\n\n> Sergey Organov wrote:\n>> Felipe Contreras writes:\n>> > Sergey Organov wrote:\n>> >> Felipe Contreras writes:\n>> >> > Sergey Organov wrote:\n>\n>> >> >> [pull]\n>> >> >> \trebase = merges\n>> >> >\n>> >> > Can you do `git pull --rebase=merges` for a while?\n>> >> \n>> >> I never use 'git pull' for merging, and all the time with rebasing, so\n>> >> what's the point? I mean, whenever I do 'git pull' I mean 'git pull\n>> >> --rebase', and whenever I need to merge, I exclusively use'git merge'.\n>> >\n>> > So you can remove that configuration.\n>> \n>> Sorry, I can't, see below.\n>> \n>> > And afterwareds set pull.rebase=true so you don't need to specify\n>> > --rebase.\n>> \n>> I don't get it. What's the point using pull.rebase=true instead of\n>> pull.rebase=merges? The former is plain total disaster in my opinion as\n>> it silently breaks history shape.\n>\n> I think there's some confusion here.\n>\n> You said you always did `git pull --rebase`, not\n> `git pull --rebase=merges`.\n\nYep, I was lazy and didn't say `git pull --rebase=merges`, sorry for\nconfusion.\n\nThough in fact my phrase was meant to stress that I use rebase as\nopposed to merge, and I left the details, in fact because I thought\n--rebase=merges sounds even more confusing in this context.\n\nThanks,\n-- Sergey Organov\n"},{"id":"426274","messageId":"xmqqeedj7qwl.fsf@gitster.g","threadId":"55814","inReplyTo":"87eedktq4x.fsf@osv.gnss.ru","subject":"Re: The git spring cleanup challenge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-03T00:06:34Z","receivedAt":"2021-06-03T00:06:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov writes:\n\n>>> [push]\n>>> \tdefault = simple\n>>\n>> This is the default, you don't need it.\n>\n> Yep, a remnant from the past.\n\nThis reminds me of something.\n\nThis particular remnant is there because the user was an early\nadopter from the days before the 'simple' setting was made the\ndefault, and it is a common pattern in our configuration variable\nsettings. We introduce a knob to allow early adopters to experience\nnew settings, and after a while, one of them may become the default,\nand at that point, the setting the user has appears redundant.\n\nIf we had a central registry of configuration variables and their\ndefault values (there isn't one), one could write a configuration\nlinter to point out \"you have this set, but it is the default these\ndays\" to remind you, which sometimes may be useful.\n\nI say \"sometimes\" because the reason why the user has a seemingly\nredundant setting may be because the default for the variable in\nquestion is planned to change, and the user has it set to keep the\ncurrent default---the opposite of the 'early adopter' use case.\n\nBeing reminded may still be useful in such a case, but the linter\ntool certainly should not make any change blindly in the name of\nremoving redundant setting without consulting the user.\n\n\n"},{"id":"426276","messageId":"CABPp-BH7f+sM_POEsSSvmz_p=oEzHQcvTk_cEhTGeb-yq9fq_A@mail.gmail.com","threadId":"55814","inReplyTo":"87wnrd6wqj.fsf@osv.gnss.ru","subject":"Re: The git spring cleanup challenge","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-03T00:26:37Z","receivedAt":"2021-06-03T00:27:51Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov wrote:\n>\n> Felipe Contreras writes:\n>\n> > Hello,\n> >\n>\n> [...]\n>\n> > These are the configurations I've chosen:\n> >\n> > [merge]\n> > conflictstyle = diff3\n> > [sendemail]\n> > smtpserver = /usr/bin/msmtp\n> >\n>\n> [pull]\n> rebase = merges\n> [push]\n> default = simple\n> [rerere]\n> enabled = true\n> autoupdate = true\n> [diff]\n> algorithm = patience\n\nAny reason for patience vs. histogram?\n\n> [merge]\n> conflictStyle = diff3\n>\n\nAnyway, here's my list to join in on the fun...\n\n[branch]\n sort = authordate\n[alias]\n brief = !git log --no-walk --abbrev=12 --pretty=reference\n[log]\n mailmap = true\n[merge]\n conflictStyle = diff3\n directoryRenames = true\n[protocol]\n version = 2\n[feature]\n experimental = true\n[pull]\n twohead = ort\n[diff]\n renameLimit = 3000\n\n(I have branch.sort=committerdate on another machine; not sure why I\nwas inconsistent, and yes now that I look at it I'm pretty sure two of\nthese have since become the default.)\n"},{"id":"426277","messageId":"60b826d968743_184d1720876@natae.notmuch","threadId":"55814","inReplyTo":"xmqqeedj7qwl.fsf@gitster.g","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-03T00:48:25Z","receivedAt":"2021-06-03T00:48:42Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Sergey Organov writes:\n> \n> >>> [push]\n> >>> \tdefault = simple\n> >>\n> >> This is the default, you don't need it.\n> >\n> > Yep, a remnant from the past.\n> \n> This reminds me of something.\n> \n> This particular remnant is there because the user was an early\n> adopter from the days before the 'simple' setting was made the\n> default, and it is a common pattern in our configuration variable\n> settings. We introduce a knob to allow early adopters to experience\n> new settings, and after a while, one of them may become the default,\n> and at that point, the setting the user has appears redundant.\n> \n> If we had a central registry of configuration variables and their\n> default values (there isn't one), one could write a configuration\n> linter to point out \"you have this set, but it is the default these\n> days\" to remind you, which sometimes may be useful.\n> \n> I say \"sometimes\" because the reason why the user has a seemingly\n> redundant setting may be because the default for the variable in\n> question is planned to change, and the user has it set to keep the\n> current default---the opposite of the 'early adopter' use case.\n\nLong time ago I proposed a core.mode configuration that would be useful\nfor this predicament too [1].\n\nWhen a configuration is planned to change, git_mode = MODE_NEXT would\nmake the new values the default.\n\nTherefore the linter could do:\n\n git_mode = MODE_CURRENT;\n git_config_default_get.. &old_default);\n\n git_mode = MODE_NEXT;\n git_config_default_get.. &new_default);\n\nIf the values are the same, that means there's no plans to change the\ndefault, and therefore it's safe to delete the configuration if the user\nhas the same value.\n\nCheers.\n\n[1] https://lore.kernel.org/git/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"426279","messageId":"60b832316cfa8_187c7d20826@natae.notmuch","threadId":"55814","inReplyTo":"CABPp-BH7f+sM_POEsSSvmz_p=oEzHQcvTk_cEhTGeb-yq9fq_A@mail.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-03T01:36:49Z","receivedAt":"2021-06-03T01:36:56Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov wrote:\n\n> > [diff]\n> > algorithm = patience\n> \n> Any reason for patience vs. histogram?\n\nIs histogram better than default?\n\n> > [merge]\n> > conflictStyle = diff3\n> >\n> \n> Anyway, here's my list to join in on the fun...\n> \n> [branch]\n> sort = authordate\n\nNice. I didn't know that existed.\n\nI have `tag.sort = -version:refname`, and after a few days without I'm\nwondering why it isn't the default.\n\n> [alias]\n> brief = !git log --no-walk --abbrev=12 --pretty=reference\n\nI find it odd that you prefer `git log --no-walk` over\n`git show --quiet`.\n\n> [log]\n> mailmap = true\n\nAnother one that I don't see why it isn't the default.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"426291","messageId":"xmqqmts764ae.fsf@gitster.g","threadId":"55814","inReplyTo":"87im2wtqg2.fsf@osv.gnss.ru","subject":"Re: The git spring cleanup challenge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-06-03T03:00:25Z","receivedAt":"2021-06-03T03:00:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov writes:\n\n> I'm second here. Wanted to get rid of some recorded resolutions, but\n> didn't find a suitable way to.\n\nJ6t gave a good summary on a side thread. \"rerere forget\" followed\nby \"checkout -m\" is your friend (alternatively you can redo the\noperation that applied a \"wrong\" resolution after doing the \"rerere\nforget\" step, of course).\n"},{"id":"426293","messageId":"CABPp-BEwueg9V0PHUZ=ZUrTRpqwqN2b2b3t4owkizr75a+BDUA@mail.gmail.com","threadId":"55814","inReplyTo":"60b832316cfa8_187c7d20826@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-03T04:25:21Z","receivedAt":"2021-06-03T04:26:47Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Jun 2, 2021 at 6:36 PM Felipe Contreras\n wrote:\n>\n> Elijah Newren wrote:\n> > On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov wrote:\n>\n> > > [diff]\n> > > algorithm = patience\n> >\n> > Any reason for patience vs. histogram?\n>\n> Is histogram better than default?\n\nYes, definitely. I think diff.algorithm should default to histogram,\npersonally.\n\nSee also commits 85551232b56e (perf: compare diff algorithms,\n2012-03-06) and c8017176ac8f (merge-ort: use histogram diff,\n2020-12-13).\n\n> > > [merge]\n> > > conflictStyle = diff3\n> > >\n> >\n> > Anyway, here's my list to join in on the fun...\n> >\n> > [branch]\n> > sort = authordate\n>\n> Nice. I didn't know that existed.\n>\n> I have `tag.sort = -version:refname`, and after a few days without I'm\n> wondering why it isn't the default.\n>\n> > [alias]\n> > brief = !git log --no-walk --abbrev=12 --pretty=reference\n>\n> I find it odd that you prefer `git log --no-walk` over\n> `git show --quiet`.\n\nWhy? Both log and show require an extra flag, so why should the\nchoice matter or be surprising?\n\nI happen to use log a lot more than show, so I think in terms of\nadding flags to git log rather than the ones I need to add to git\nshow. Not a big deal either way, though.\n\n> > [log]\n> > mailmap = true\n>\n> Another one that I don't see why it isn't the default.\n\nIt is the default and has been for a couple years; see f3eda90ffc10\n(log: really flip the --mailmap default, 2019-08-01). I just never\ncleaned up my config.\n"},{"id":"426307","messageId":"87eedj74dr.fsf@evledraar.gmail.com","threadId":"55814","inReplyTo":"60b70eb930614_4abd208ad@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-03T08:03:25Z","receivedAt":"2021-06-03T08:14:19Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Jun 01 2021, Felipe Contreras wrote:\n\n> Đoàn Trần Công Danh wrote:\n>> On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n>> > > How about alias? It's part of my muscle memory.\n>> > \n>> > No aliases.\n>> > \n>> > If a new user doesn't have them, neither should you.\n>> > \n>> > All VCSs have default aliases, and I advocated for git to do the same\n>> > [1], but it wasn't accepted.\n>> > \n>> > The whole point is to suffer like them.\n>> \n>> Get back to the alias topic.\n>> I also agree with other people's opinion in that thread.\n>> IOW, I support the decision to not accept those default alias ;)\n>\n> Why?\n>\n>> It's not required to be different people to have alias defined to\n>> different command. I have alias conditionally defined to different\n>> command based on git-dir. For example, I had ci alias to \"commit\" by\n>> default, and \"commit -s\" on other repositories.\n>\n> So? They would still work.\n>\n>> So, Git decides alias for me will not only break my current alias, but\n>> also break my conditional alias.\n>\n> No it wouldn't. They are *default* aliases, not overriding aliases. They\n> would be used only if you haven't set the same alias yourself.\n>\n> Try it.\n>\n> --- a/alias.c\n> +++ b/alias.c\n> @@ -28,13 +28,27 @@ static int config_alias_cb(const char *key, const char *value, void *d)\n> return 0;\n> }\n> \n> +struct config_alias_data default_aliases[] = {\n> + { \"co\", \"checkout\" },\n> + { \"ci\", \"checkout\" },\n> + { \"rb\", \"rebase\" },\n> + { \"st\", \"status\" },\n> +};\n> +\n> char *alias_lookup(const char *alias)\n> {\n> struct config_alias_data data = { alias, NULL };\n> + int i;\n> \n> read_early_config(config_alias_cb, &data);\n> + if (data.v)\n> + return data.v;\n> + for (i = 0; i < ARRAY_SIZE(default_aliases); i++) {\n> + if (!strcmp(alias, default_aliases[i].alias))\n> + return xstrdup(default_aliases[i].v);\n> + }\n> \n> - return data.v;\n> + return NULL;\n> }\n> \n> void list_aliases(struct string_list *list)\n>\n>\n>> Anyway, remotes/branches are all configuration values.\n>> Would you prefer:\n>\n> I meant global configurations. If it's a per-repository setting surely\n> it wouldn't be something amenable for the Git project to set as default.\n\nI agree with this batteries included sentiment, but would very much like\nto not see this as hardcoding of ours, but us shipping optional config\nfiles to be included.\n\nWe could then just extend the include syntax rather easily to include\n\"libraries\", which would be like the current include.path, but would\nunderstand a library:: prefix (better name bikeshedding welcome). We'd\nthen just ship these in /usr/share/git-core/config/includes or whatever,\ne.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg\n\nPart of that goes against what I was arguing for in [1], but I suppose\nif that's a problem we could always optionally compile these in (in\nGo-like fashion), while retaining the semantics.\n\nThe advantage of doing that is that you don't have to bless one set of\naliases, e.g. you could have cvs-like.cfg, svn-like.cfg etc.\n\n1. https://lore.kernel.org/git/87czvoowg2.fsf@evledraar.gmail.com/\n"},{"id":"426308","messageId":"87bl8n73om.fsf@evledraar.gmail.com","threadId":"55814","inReplyTo":"60b5d281552d6_e359f20828@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-03T08:15:48Z","receivedAt":"2021-06-03T08:28:13Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Jun 01 2021, Felipe Contreras wrote:\n\n> 1. Remove all the configuration that is not essential (just leave\n> user.name and user.email or equivalent)\n> 2. Pick 2 configurations you think you can't live without. You are not\n> allowed to change them afterwards.\n> 3. Every day you can add 1 additional configuration (and update it the\n> next day).\n> 4. The moment you add a 4th configuration you lose.\n\nThis proposal is somewhere between picking which 2 of your 4 kids gets\nto live and asking an alcoholic to stop drinking for a week just so he\ncan tell you at the end what his favorite drinks are :)\n\nSo I skipped the \"disable most config\", but for what it's worth I think\nI'd miss these the most, I couldn't pick just N favorites, sorry:\n\n * diff.colorMoved=true: super useful, but I'd be vary of turning it on\n by default in its current form. E.g. on gcc.git's changelog files it\n has really pathological performance characteristics.\n\n * rebase.rescheduleFailedExec=true: Relatively new, but I'd find it\n hard to live without this now.\n\n * rerere.*: others have mentioned \"should be enabled by default\".\n\n But on that topic I set gc.rerereResolved=\"1 year ago\", with\n managing/merging topics in git.git the default of 60 days is way too\n aggressive.\n\n * merge.defaultToUpstream: ditto other discussion, should be \"true\" by\n default.\n\n * checkout.defaultRemote=origin: I introduced this, so I'm biased, but\n I find it super useful. Usually because I do \"git branch -m\n new-branch\" on master to create topics, and then \"git checkout\n master\" to get a master back (or use the existing one).\n\n * commit.verbose=true: so you know what you're looking at in doing in\n \"git commit --amend\".\n\n * grep.patternType=perl: Another personal soap box (but really, BRE\n anywhere sucks).\n\nI also have a bunch of aliases that would not be useful to a general\naudience, but which I find I can't live without, some of the most\ncommonly used ones:\n\n # Log with \"less\" n/p already going to the next/prev commit\n log-psfd = \"!f() { PAGER=\\\"less -p'^commit'\\\" git log -p --stat --full-diff $@; }; f\"\n # cutesy commit aliases (I guess \"commit\" is both \"ci\" and \"c\" here, but...)\n cif = commit --fixup\n cis = commit --squash\n ca = commit --amend\n cane = commit --amend --no-edit\n\nSimilarly rebase is \"r\", \"--interactive\" is \"ri\", \"--abort\", and\n\"--continue\" are \"ra\" and \"rc\".\n\nIf anyone's interested in the rest / full set:\nhttps://github.com/avar/dotfiles/blob/master/.gitconfig\n \n\n"},{"id":"426312","messageId":"87pmx32s93.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"CABPp-BH7f+sM_POEsSSvmz_p=oEzHQcvTk_cEhTGeb-yq9fq_A@mail.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-03T09:48:40Z","receivedAt":"2021-06-03T09:49:56Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Elijah Newren writes:\n\n> On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov wrote:\n>>\n>> Felipe Contreras writes:\n>>\n>> > Hello,\n>> >\n>>\n>> [...]\n>>\n>> > These are the configurations I've chosen:\n>> >\n>> > [merge]\n>> > conflictstyle = diff3\n>> > [sendemail]\n>> > smtpserver = /usr/bin/msmtp\n>> >\n>>\n>> [pull]\n>> rebase = merges\n>> [push]\n>> default = simple\n>> [rerere]\n>> enabled = true\n>> autoupdate = true\n>> [diff]\n>> algorithm = patience\n>\n> Any reason for patience vs. histogram?\n\nNo, I only tried the 'patience', didn't try 'histogram'.\n\n-- Sergey Organov\n"},{"id":"426313","messageId":"60b8a659f3ff2_1a0a2d2089c@natae.notmuch","threadId":"55814","inReplyTo":"CABPp-BEwueg9V0PHUZ=ZUrTRpqwqN2b2b3t4owkizr75a+BDUA@mail.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-03T09:52:26Z","receivedAt":"2021-06-03T09:53:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> On Wed, Jun 2, 2021 at 6:36 PM Felipe Contreras\n> wrote:\n> >\n> > Elijah Newren wrote:\n> > > On Tue, Jun 1, 2021 at 3:39 PM Sergey Organov wrote:\n> >\n> > > > [diff]\n> > > > algorithm = patience\n> > >\n> > > Any reason for patience vs. histogram?\n> >\n> > Is histogram better than default?\n> \n> Yes, definitely. I think diff.algorithm should default to histogram,\n> personally.\n> \n> See also commits 85551232b56e (perf: compare diff algorithms,\n> 2012-03-06) and c8017176ac8f (merge-ort: use histogram diff,\n> 2020-12-13).\n\nInteresting. I'll give it a try after this month.\n\n> > > > [merge]\n> > > > conflictStyle = diff3\n> > > >\n> > >\n> > > Anyway, here's my list to join in on the fun...\n> > >\n> > > [branch]\n> > > sort = authordate\n> >\n> > Nice. I didn't know that existed.\n> >\n> > I have `tag.sort = -version:refname`, and after a few days without I'm\n> > wondering why it isn't the default.\n> >\n> > > [alias]\n> > > brief = !git log --no-walk --abbrev=12 --pretty=reference\n> >\n> > I find it odd that you prefer `git log --no-walk` over\n> > `git show --quiet`.\n> \n> Why? Both log and show require an extra flag, so why should the\n> choice matter or be surprising?\n\nBecause log is to list a log, and show is to show a single commit. --no-walk\nmakes sense in addition to --stdin for example.\n\nA log with a single entry doesn't seem like a log to me. But to each his\nown.\n\n> I happen to use log a lot more than show, so I think in terms of\n> adding flags to git log rather than the ones I need to add to git\n> show. Not a big deal either way, though.\n\nI'm the opposite, in fact, I barely use git log. When I want to see\nhistory I use gitk, and when I want to see a single commit `git show`.\n\n 9% show\n 7% v # alias for gitk\n 2% log\n\n> > > [log]\n> > > mailmap = true\n> >\n> > Another one that I don't see why it isn't the default.\n> \n> It is the default and has been for a couple years; see f3eda90ffc10\n> (log: really flip the --mailmap default, 2019-08-01). I just never\n> cleaned up my config.\n\nOhhh, that makes sense.\n\n-- \nFelipe Contreras\n"},{"id":"426314","messageId":"87lf7r2rpv.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"xmqqmts764ae.fsf@gitster.g","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-03T10:00:12Z","receivedAt":"2021-06-03T10:01:35Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano writes:\n\n> Sergey Organov writes:\n>\n>> I'm second here. Wanted to get rid of some recorded resolutions, but\n>> didn't find a suitable way to.\n>\n> J6t gave a good summary on a side thread. \"rerere forget\" followed\n> by \"checkout -m\" is your friend (alternatively you can redo the\n> operation that applied a \"wrong\" resolution after doing the \"rerere\n> forget\" step, of course).\n\nWell, I was not in the middle of any merge when I wanted the feature,\nand \"forget\", according to its documentation, deals with \"the current\nconflict\".\n\nAs far as I recall, I wanted rerere to just forget everything it ever\nknew about merge resolutions for all the paths in particular\nsub-directory, before I even start the merge, and I rather ended up\ndoing the merge in a fresh clone.\n\nThanks,\n-- Sergey Organov\n"},{"id":"426315","messageId":"60b8a98d11d7c_1a0a2d20856@natae.notmuch","threadId":"55814","inReplyTo":"87eedj74dr.fsf@evledraar.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-03T10:06:05Z","receivedAt":"2021-06-03T10:07:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, Jun 01 2021, Felipe Contreras wrote:\n> \n> > Đoàn Trần Công Danh wrote:\n> >> On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n> >> > > How about alias? It's part of my muscle memory.\n> >> > \n> >> > No aliases.\n> >> > \n> >> > If a new user doesn't have them, neither should you.\n> >> > \n> >> > All VCSs have default aliases, and I advocated for git to do the same\n> >> > [1], but it wasn't accepted.\n> >> > \n> >> > The whole point is to suffer like them.\n> >> \n> >> Get back to the alias topic.\n> >> I also agree with other people's opinion in that thread.\n> >> IOW, I support the decision to not accept those default alias ;)\n> >\n> > Why?\n> >\n> >> It's not required to be different people to have alias defined to\n> >> different command. I have alias conditionally defined to different\n> >> command based on git-dir. For example, I had ci alias to \"commit\" by\n> >> default, and \"commit -s\" on other repositories.\n> >\n> > So? They would still work.\n> >\n> >> So, Git decides alias for me will not only break my current alias, but\n> >> also break my conditional alias.\n> >\n> > No it wouldn't. They are *default* aliases, not overriding aliases. They\n> > would be used only if you haven't set the same alias yourself.\n> >\n> > Try it.\n> >\n> > --- a/alias.c\n> > +++ b/alias.c\n> > @@ -28,13 +28,27 @@ static int config_alias_cb(const char *key, const char *value, void *d)\n> > return 0;\n> > }\n> > \n> > +struct config_alias_data default_aliases[] = {\n> > + { \"co\", \"checkout\" },\n> > + { \"ci\", \"checkout\" },\n> > + { \"rb\", \"rebase\" },\n> > + { \"st\", \"status\" },\n> > +};\n> > +\n> > char *alias_lookup(const char *alias)\n> > {\n> > struct config_alias_data data = { alias, NULL };\n> > + int i;\n> > \n> > read_early_config(config_alias_cb, &data);\n> > + if (data.v)\n> > + return data.v;\n> > + for (i = 0; i < ARRAY_SIZE(default_aliases); i++) {\n> > + if (!strcmp(alias, default_aliases[i].alias))\n> > + return xstrdup(default_aliases[i].v);\n> > + }\n> > \n> > - return data.v;\n> > + return NULL;\n> > }\n> > \n> > void list_aliases(struct string_list *list)\n> >\n> >\n> >> Anyway, remotes/branches are all configuration values.\n> >> Would you prefer:\n> >\n> > I meant global configurations. If it's a per-repository setting surely\n> > it wouldn't be something amenable for the Git project to set as default.\n> \n> I agree with this batteries included sentiment, but would very much like\n> to not see this as hardcoding of ours, but us shipping optional config\n> files to be included.\n\nThe problem with optional config files is that you can't standardize\nthat way.\n\nIf hard-coded default aliases they can be included in the documentation.\n\nPluse we all start to typing similar commands, instead of each having\ncompletely different alias to the next.\n\nFor example in 3 days of doing this experiment I've typed 'g c'\ncountless of times (alias for `commit -v`). I added an alias for `ci`\ninstead, since that what other VCSs use, like Mercurial. But I don't\nthink `ci` makes sense for commit. It would be better if `co` was\navailable, but then checkout needs another alias.\n\nIf we could replace checkout with switch, then we could have an alias\n`sw` for switch, and another `co` for commit.\n\nBut that requires that switch is actually usable (it isn't for me right\nnow).\n\nThis increases the urgency to fix `git switch` for me. If other\ndevelopers were trying the same aliases they might see the same issues.\n\n> We could then just extend the include syntax rather easily to include\n> \"libraries\", which would be like the current include.path, but would\n> understand a library:: prefix (better name bikeshedding welcome). We'd\n> then just ship these in /usr/share/git-core/config/includes or whatever,\n> e.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg\n\nI wouldn't be against some some suggested defaults, but *in addition* to\nsome hardcoded default aliases that are documented.\n\n\nI have been using git without aliases for 2 days, and I'm already fed up.\n\n-- \nFelipe Contreras"},{"id":"426319","messageId":"87im2v1aun.fsf@osv.gnss.ru","threadId":"55814","inReplyTo":"60b8a98d11d7c_1a0a2d20856@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-06-03T10:49:52Z","receivedAt":"2021-06-03T10:50:11Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Felipe Contreras writes:\n\n\n[...]\n\n>\n> For example in 3 days of doing this experiment I've typed 'g c'\n> countless of times (alias for `commit -v`). I added an alias for `ci`\n> instead, since that what other VCSs use, like Mercurial. But I don't\n> think `ci` makes sense for commit. It would be better if `co` was\n> available, but then checkout needs another alias.\n\nI guess 'ci' historically means \"check in\", as opposed to 'co' meaning\n\"check out\", probably in RCS.\n\nThanks,\n-- Sergey Organov\n"},{"id":"426320","messageId":"60b8b882b9dc5_1a0a2d208e9@natae.notmuch","threadId":"55814","inReplyTo":"87bl8n73om.fsf@evledraar.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-03T11:09:54Z","receivedAt":"2021-06-03T11:10:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, Jun 01 2021, Felipe Contreras wrote:\n> \n> > 1. Remove all the configuration that is not essential (just leave\n> > user.name and user.email or equivalent)\n> > 2. Pick 2 configurations you think you can't live without. You are not\n> > allowed to change them afterwards.\n> > 3. Every day you can add 1 additional configuration (and update it the\n> > next day).\n> > 4. The moment you add a 4th configuration you lose.\n> \n> This proposal is somewhere between picking which 2 of your 4 kids gets\n> to live and asking an alcoholic to stop drinking for a week just so he\n> can tell you at the end what his favorite drinks are :)\n\nYeah, but if you can't enjoy life without alcohol, you probably have a\nproblem.\n\nAre you saying vanilla git is *that* bad?\n\n> So I skipped the \"disable most config\", but for what it's worth I think\n> I'd miss these the most, I couldn't pick just N favorites, sorry:\n> \n> * diff.colorMoved=true: super useful, but I'd be vary of turning it on\n> by default in its current form. E.g. on gcc.git's changelog files it\n> has really pathological performance characteristics.\n\nVery nice! I didn't know about it. I'll pick it for my third day.\n\n> * merge.defaultToUpstream: ditto other discussion, should be \"true\" by\n> default.\n\nThat is the default. I used it as an example of a configuration that\nchanged default (I did it in 2014).\n\n(I just noticed the documentation of the config wasn't updated).\n\n> * checkout.defaultRemote=origin: I introduced this, so I'm biased, but\n> I find it super useful. Usually because I do \"git branch -m\n> new-branch\" on master to create topics, and then \"git checkout\n> master\" to get a master back (or use the existing one).\n\nThat is useful, but I don't think it's aptly named, it should be\nsomething like checkout.autoUpstream. The name of the default branch\nbelongs elsewhere.\n\nI would say core.defaultRemote.\n\nRight now for example `git fetch` defaults to a hard-coded \"origin\".\nDoesn't make much sense that the remote for automatic upstream checkout\ncan be configured, but not the one `git fetch` uses.\n\n> * commit.verbose=true: so you know what you're looking at in doing in\n> \"git commit --amend\".\n\nAha! My alias had `commit -v` but I would want this on all commit\ncommands.\n\nMoreover, I was thinking on suggesting this by default. Who would it\nhurt?\n\n> * grep.patternType=perl: Another personal soap box (but really, BRE\n> anywhere sucks).\n\nNice. `git grep` is the #2 command I use the most, and I often need to\nspecify another regexp because the basic one doesn't understand what I'm\ntrying to do.\n\n> I also have a bunch of aliases that would not be useful to a general\n> audience, but which I find I can't live without, some of the most\n> commonly used ones:\n> \n> # Log with \"less\" n/p already going to the next/prev commit\n> log-psfd = \"!f() { PAGER=\\\"less -p'^commit'\\\" git log -p --stat --full-diff $@; }; f\"\n\nVery neat.\n\n> Similarly rebase is \"r\", \"--interactive\" is \"ri\", \"--abort\", and\n> \"--continue\" are \"ra\" and \"rc\".\n\nI have almost the same, except rbi, rbc, and rba. My 'r' is reset, but\nsince I use rebase more often I guess I should switch them up.\n\nTheres are a couple of mine:\n\n advance = merge --ff-only\n undo = reset --hard @{1}\n \n> If anyone's interested in the rest / full set:\n> https://github.com/avar/dotfiles/blob/master/.gitconfig\n\nIs thata private repo?\n\nHere are mine:\n\nhttps://github.com/felipec/dotfiles/blob/master/.gitconfig\n\n-- \nFelipe Contreras"},{"id":"426321","messageId":"87zgw75dyi.fsf@evledraar.gmail.com","threadId":"55814","inReplyTo":"60b8a98d11d7c_1a0a2d20856@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-03T12:18:15Z","receivedAt":"2021-06-03T12:30:14Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jun 03 2021, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> \n>> On Tue, Jun 01 2021, Felipe Contreras wrote:\n>> \n>> > Đoàn Trần Công Danh wrote:\n>> >> On 2021-06-01 05:48:41-0500, Felipe Contreras wrote:\n>> >> > > How about alias? It's part of my muscle memory.\n>> >> > \n>> >> > No aliases.\n>> >> > \n>> >> > If a new user doesn't have them, neither should you.\n>> >> > \n>> >> > All VCSs have default aliases, and I advocated for git to do the same\n>> >> > [1], but it wasn't accepted.\n>> >> > \n>> >> > The whole point is to suffer like them.\n>> >> \n>> >> Get back to the alias topic.\n>> >> I also agree with other people's opinion in that thread.\n>> >> IOW, I support the decision to not accept those default alias ;)\n>> >\n>> > Why?\n>> >\n>> >> It's not required to be different people to have alias defined to\n>> >> different command. I have alias conditionally defined to different\n>> >> command based on git-dir. For example, I had ci alias to \"commit\" by\n>> >> default, and \"commit -s\" on other repositories.\n>> >\n>> > So? They would still work.\n>> >\n>> >> So, Git decides alias for me will not only break my current alias, but\n>> >> also break my conditional alias.\n>> >\n>> > No it wouldn't. They are *default* aliases, not overriding aliases. They\n>> > would be used only if you haven't set the same alias yourself.\n>> >\n>> > Try it.\n>> >\n>> > --- a/alias.c\n>> > +++ b/alias.c\n>> > @@ -28,13 +28,27 @@ static int config_alias_cb(const char *key, const char *value, void *d)\n>> > return 0;\n>> > }\n>> > \n>> > +struct config_alias_data default_aliases[] = {\n>> > + { \"co\", \"checkout\" },\n>> > + { \"ci\", \"checkout\" },\n>> > + { \"rb\", \"rebase\" },\n>> > + { \"st\", \"status\" },\n>> > +};\n>> > +\n>> > char *alias_lookup(const char *alias)\n>> > {\n>> > struct config_alias_data data = { alias, NULL };\n>> > + int i;\n>> > \n>> > read_early_config(config_alias_cb, &data);\n>> > + if (data.v)\n>> > + return data.v;\n>> > + for (i = 0; i < ARRAY_SIZE(default_aliases); i++) {\n>> > + if (!strcmp(alias, default_aliases[i].alias))\n>> > + return xstrdup(default_aliases[i].v);\n>> > + }\n>> > \n>> > - return data.v;\n>> > + return NULL;\n>> > }\n>> > \n>> > void list_aliases(struct string_list *list)\n>> >\n>> >\n>> >> Anyway, remotes/branches are all configuration values.\n>> >> Would you prefer:\n>> >\n>> > I meant global configurations. If it's a per-repository setting surely\n>> > it wouldn't be something amenable for the Git project to set as default.\n>> \n>> I agree with this batteries included sentiment, but would very much like\n>> to not see this as hardcoding of ours, but us shipping optional config\n>> files to be included.\n>\n> The problem with optional config files is that you can't standardize\n> that way.\n>\n> If hard-coded default aliases they can be included in the documentation.\n>\n> Pluse we all start to typing similar commands, instead of each having\n> completely different alias to the next.\n>\n> For example in 3 days of doing this experiment I've typed 'g c'\n> countless of times (alias for `commit -v`). I added an alias for `ci`\n> instead, since that what other VCSs use, like Mercurial. But I don't\n> think `ci` makes sense for commit. It would be better if `co` was\n> available, but then checkout needs another alias.\n>\n> If we could replace checkout with switch, then we could have an alias\n> `sw` for switch, and another `co` for commit.\n>\n> But that requires that switch is actually usable (it isn't for me right\n> now).\n>\n> This increases the urgency to fix `git switch` for me. If other\n> developers were trying the same aliases they might see the same issues.\n>\n>> We could then just extend the include syntax rather easily to include\n>> \"libraries\", which would be like the current include.path, but would\n>> understand a library:: prefix (better name bikeshedding welcome). We'd\n>> then just ship these in /usr/share/git-core/config/includes or whatever,\n>> e.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg\n>\n> I wouldn't be against some some suggested defaults, but *in addition* to\n> some hardcoded default aliases that are documented.\n\nI'm talking about in terms of the flexibility of implementation of\non-by-default defaults. We could implement it as I suggested and then\njust have a core.defaultIncludes, which would by default be set to\ngit::aliases/svn-like.cfg or whatever, i.e. equivalent to:\n\n [core]\n defaultIncludes = \"git::default.cfg\"\n\nWhich itself would include a\n/usr/share/git-core/config/includes/default.cfg which would do:\n\n [include]\n path = \"git::aliases/svn-like.cfg\"\n paht = \n\nSo it would work out of the box on a vanilla git install, you could then\nin ~/.gitconfig or whatever set:\n\n [core]\n defaultIncludes = false\n\nOr whatever, which we'd check for early with repo_config_get_bool() (see\nrepo-settings.c).\n\nSo you'd have an out from these optional vanilla includes. Then to\naddress the concern in [1] we could (sans the user-diff specific\nlimitations in that thread) treat the default userdiff \"config\" this way\nand (optionally) slurp these up into a generated *.c file at build-time.\n\nIn a way this is total bikeshedding, I just think it's worth doing it\nthis way up-front.\n\nIt gives you a lot more flexibility than hardcoding these in the source\nsomewhere. It becomes easy e.g. to have multiple \"default\" variants, so\nfeature.experimental or whatever could give you early opt-in to new\naliases, or the other way around of new versions maintaining\ncompatibility with older style invocations via aliases.\n\n1. https://lore.kernel.org/git/87czvoowg2.fsf@evledraar.gmail.com/\n"},{"id":"426323","messageId":"87wnrb5cvl.fsf@evledraar.gmail.com","threadId":"55814","inReplyTo":"60b8b882b9dc5_1a0a2d208e9@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-03T12:31:59Z","receivedAt":"2021-06-03T12:52:37Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jun 03 2021, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> So I skipped the \"disable most config\", but for what it's worth I think\n>> I'd miss these the most, I couldn't pick just N favorites, sorry:\n>> \n>> * diff.colorMoved=true: super useful, but I'd be vary of turning it on\n>> by default in its current form. E.g. on gcc.git's changelog files it\n>> has really pathological performance characteristics.\n>\n> Very nice! I didn't know about it. I'll pick it for my third day.\n\nIt makes patch review a lot easier, and also integrates nicely with -w.\n\n>> * merge.defaultToUpstream: ditto other discussion, should be \"true\" by\n>> default.\n>\n> That is the default. I used it as an example of a configuration that\n> changed default (I did it in 2014).\n>\n> (I just noticed the documentation of the config wasn't updated).\n\nHa! Maybe it's leftover from before then, or I missed that in the\nnot-updated docs more recently.\n\n>> * checkout.defaultRemote=origin: I introduced this, so I'm biased, but\n>> I find it super useful. Usually because I do \"git branch -m\n>> new-branch\" on master to create topics, and then \"git checkout\n>> master\" to get a master back (or use the existing one).\n>\n> That is useful, but I don't think it's aptly named, it should be\n> something like checkout.autoUpstream. The name of the default branch\n> belongs elsewhere.\n>\n> I would say core.defaultRemote.\n>\n> Right now for example `git fetch` defaults to a hard-coded \"origin\".\n> Doesn't make much sense that the remote for automatic upstream checkout\n> can be configured, but not the one `git fetch` uses.\n\nI think there was some bikeshedding around that time. I share the\nsentiment, but worry about \"core\" over-configuring such a\nthing. E.g. wanting \"checkout\" to search a \"upstream\" and \"origin\" in\nthat order (not that it supports a list right now, but could) != wanting\n\"init\" to use \"upstream\" instead of \"origin\" by default.\n\n>> * commit.verbose=true: so you know what you're looking at in doing in\n>> \"git commit --amend\".\n>\n> Aha! My alias had `commit -v` but I would want this on all commit\n> commands.\n>\n> Moreover, I was thinking on suggesting this by default. Who would it\n> hurt?\n\nE.g. \"git rebase -i\" with \"reword\" now becomes a lot more verbose, I\nthink it's a feature, but others might disagree.\n\nIt also exposes various edge cases around our parsing of the diff\nv.s. commit message content in our apply.c etc. code, e.g. say you want\nto blindly search-replace \"diff\" with \"difference\" in your commit\nmessages. You'll now change the \"diff --git\" line to \"difference --git\",\nand now \"commit\" won't detect that it's the patch part anymore, and\nmerge that diff into your commit message itself.\n\nI can't remember if we pick up on \"diff --git\" exactly, IIRC, but\nanyway, whatever part of the format you need to screw with, the point\nstands. I've run into mistakes like that in the past, one recently made\nit to this ML.\n\n>> * grep.patternType=perl: Another personal soap box (but really, BRE\n>> anywhere sucks).\n>\n> Nice. `git grep` is the #2 command I use the most, and I often need to\n> specify another regexp because the basic one doesn't understand what I'm\n> trying to do.\n\nYeah, it should be at least ERE by default, Something for Git v3.0 ...?\n\n>> I also have a bunch of aliases that would not be useful to a general\n>> audience, but which I find I can't live without, some of the most\n>> commonly used ones:\n>> \n>> # Log with \"less\" n/p already going to the next/prev commit\n>> log-psfd = \"!f() { PAGER=\\\"less -p'^commit'\\\" git log -p --stat --full-diff $@; }; f\"\n>\n> Very neat.\n\nI think similar to your \"git help xyz\" patches having coloring, we\nreally should consider things like that by default knowing that we're\ninvoking \"less\". I.e. if we got over the notion that our job is just to\nthrow data over the wall to \"man\" or the pager without any further\ntweaking or integration.\n\n>> Similarly rebase is \"r\", \"--interactive\" is \"ri\", \"--abort\", and\n>> \"--continue\" are \"ra\" and \"rc\".\n>\n> I have almost the same, except rbi, rbc, and rba. My 'r' is reset, but\n> since I use rebase more often I guess I should switch them up.\n>\n> Theres are a couple of mine:\n>\n> advance = merge --ff-only\n> undo = reset --hard @{1}\n> \n>> If anyone's interested in the rest / full set:\n>> https://github.com/avar/dotfiles/blob/master/.gitconfig\n>\n> Is thata private repo?\n>\n> Here are mine:\n>\n> https://github.com/felipec/dotfiles/blob/master/.gitconfig\n\nYes, it was private[1]. I've made it public again.\n\n1. It used to be public, but then the security/auditing people at an\n ex-job kept pestering me about me hardcoding über-secret company data\n in public GitHub repos.\n\n They didn't find questions like \"uh, you mean this information we\n advertise in an MX lookup to our public nameservers?\", or \"yes,\n that's my company E-Mail address in a config file, my co-workers have\n the same info on linkedin\" all that convincing. Anyway, it's back now\n :)\n"},{"id":"426328","messageId":"dbbb5a73-12b5-27a1-63d4-eece1e60f57b@gmail.com","threadId":"55814","inReplyTo":"87wnrb5cvl.fsf@evledraar.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-06-03T14:28:35Z","receivedAt":"2021-06-03T14:29:39Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Ævar\n\nOn 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Jun 03 2021, Felipe Contreras wrote:\n> \n>> Ævar Arnfjörð Bjarmason wrote:\n>>> So I skipped the \"disable most config\", but for what it's worth I think\n>>> I'd miss these the most, I couldn't pick just N favorites, sorry:\n>>>\n>>> * diff.colorMoved=true: super useful, but I'd be vary of turning it on\n>>> by default in its current form. E.g. on gcc.git's changelog files it\n>>> has really pathological performance characteristics.\n\nWould you be able say a bit more about this so I can try and reproduce \nit please. I'm working on some patches [1] to improve the performance of \n`diff --color-moved` and `diff --color-moved-ws` and it would be good to \ntest them on a problematic repo. At the moment I diffing two releases of \ngit to test performance on a large diff. I just cloned the last 18 \nmonths of gcc.git and Changelog seems to just be appended to.\n\n>> Very nice! I didn't know about it. I'll pick it for my third day.\n> \n> It makes patch review a lot easier, and also integrates nicely with -w.\n\nI find --color-moved-ws=allow-indentation-change helpful as well (it is \nquite a bit slower at the moment but I have some patches to bring it up \nto the speed of the other --color-moved modes.\n\n[1] https://github.com/phillipwood/git/tree/wip/diff-color-moved-tweaks\n\n> [...]\n>>> * commit.verbose=true: so you know what you're looking at in doing in\n>>> \"git commit --amend\".\n>>\n>> Aha! My alias had `commit -v` but I would want this on all commit\n>> commands.\n>>\n>> Moreover, I was thinking on suggesting this by default. Who would it\n>> hurt?\n> \n> E.g. \"git rebase -i\" with \"reword\" now becomes a lot more verbose, I\n> think it's a feature, but others might disagree.\n> \n> It also exposes various edge cases around our parsing of the diff\n> v.s. commit message content in our apply.c etc. code, e.g. say you want\n> to blindly search-replace \"diff\" with \"difference\" in your commit\n> messages. You'll now change the \"diff --git\" line to \"difference --git\",\n> and now \"commit\" won't detect that it's the patch part anymore, and\n> merge that diff into your commit message itself.\n> \n> I can't remember if we pick up on \"diff --git\" exactly, IIRC, but\n> anyway, whatever part of the format you need to screw with, the point\n> stands. I've run into mistakes like that in the past, one recently made\n> it to this ML.\n\nI think the problem occurs if the scissors line gets messed up when \nediting the commit message\n\n>[...] \n>>> I also have a bunch of aliases that would not be useful to a general\n>>> audience, but which I find I can't live without, some of the most\n>>> commonly used ones:\n>>>\n>>> # Log with \"less\" n/p already going to the next/prev commit\n>>> log-psfd = \"!f() { PAGER=\\\"less -p'^commit'\\\" git log -p --stat --full-diff $@; }; f\"\n>>\n>> Very neat.\n> \n> I think similar to your \"git help xyz\" patches having coloring, we\n> really should consider things like that by default knowing that we're\n> invoking \"less\". I.e. if we got over the notion that our job is just to\n> throw data over the wall to \"man\" or the pager without any further\n> tweaking or integration.\n\nSpeaking personally it is not that I think that we should just throw \ndata over the all to \"man\" but that if colors are a good idea we should \nbe thinking about the whole ecosystem and working with distributions or \nthe man authors to ensure all programs and users benefit from it not \njust git.\n\nBest Wishes\n\nPhillip\n"},{"id":"426333","messageId":"87tume6g0g.fsf@evledraar.gmail.com","threadId":"55814","inReplyTo":"dbbb5a73-12b5-27a1-63d4-eece1e60f57b@gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-06-03T16:44:52Z","receivedAt":"2021-06-03T17:00:44Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Jun 03 2021, Phillip Wood wrote:\n\n> Hi Ævar\n>\n> On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:\n>> On Thu, Jun 03 2021, Felipe Contreras wrote:\n>> \n>>> Ævar Arnfjörð Bjarmason wrote:\n>>>> So I skipped the \"disable most config\", but for what it's worth I think\n>>>> I'd miss these the most, I couldn't pick just N favorites, sorry:\n>>>>\n>>>> * diff.colorMoved=true: super useful, but I'd be vary of turning it on\n>>>> by default in its current form. E.g. on gcc.git's changelog files it\n>>>> has really pathological performance characteristics.\n>\n> Would you be able say a bit more about this so I can try and reproduce\n> it please. I'm working on some patches [1] to improve the performance\n> of `diff --color-moved` and `diff --color-moved-ws` and it would be\n> good to test them on a problematic repo. At the moment I diffing two\n> releases of git to test performance on a large diff. I just cloned the\n> last 18 months of gcc.git and Changelog seems to just be appended to.\n\nI misremembered the gcc.git ChangeLog issue, sorry. That's about\nsomething else entirely.\n\nThe issue with the color moved code can just be reproduced on most large\ndiffs, e.g. on git.git:\n \n $ time git diff --color-moved=true v2.25.0..v2.30.0 >/dev/null\n real 0m10.112s\n $ time git diff --color-moved=false v2.25.0..v2.30.0 >/dev/null\n real 0m0.939s\n\nSo 10x slower, and e.g. diffing from v2.22.0 makes it 25s and 1.1s,\nrespectively.\n\nIn some sense that slowness is expected, it simly takes time to compute\nthis. I think for turning it on by default we should have something like\nthe diff.renameLimit, and change the default to some \"auto\" that would\npunt out if it was taking too long to compute.\n\nI run with it by default so this doesn't bother me, but I think it's\nprobably a semi-common use-case of some people to e.g. diff the last N\nreleases of Linux, and then use their pager to search around in the\ndiff.\n\nWe don't want commands like that to take 25s instead of 1s, but I think\nit would be fine (and we should) warn that we aborted on the color move\nif it's otherwise the default.\n\nOtherwise it'll take 1s, and if you normally depend on it you'll\nconclude that some code you're looking at wasn't moved, which would also\nsuck, better to punt on it and warn, just like the diff.renameLimit.\n\n\n>>> Very nice! I didn't know about it. I'll pick it for my third day.\n>> It makes patch review a lot easier, and also integrates nicely with\n>> -w.\n>\n> I find --color-moved-ws=allow-indentation-change helpful as well (it\n> is quite a bit slower at the moment but I have some patches to bring\n> it up to the speed of the other --color-moved modes.\n>\n> [1] https://github.com/phillipwood/git/tree/wip/diff-color-moved-tweaks\n\nNice, I didn't know about that option. Will try it.\n"},{"id":"426334","messageId":"60b91152dd007_258801208b7@natae.notmuch","threadId":"55814","inReplyTo":"87wnrb5cvl.fsf@evledraar.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-03T17:28:50Z","receivedAt":"2021-06-03T17:29:06Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Thu, Jun 03 2021, Felipe Contreras wrote:\n\n> >> * checkout.defaultRemote=origin: I introduced this, so I'm biased, but\n> >> I find it super useful. Usually because I do \"git branch -m\n> >> new-branch\" on master to create topics, and then \"git checkout\n> >> master\" to get a master back (or use the existing one).\n> >\n> > That is useful, but I don't think it's aptly named, it should be\n> > something like checkout.autoUpstream. The name of the default branch\n> > belongs elsewhere.\n> >\n> > I would say core.defaultRemote.\n> >\n> > Right now for example `git fetch` defaults to a hard-coded \"origin\".\n> > Doesn't make much sense that the remote for automatic upstream checkout\n> > can be configured, but not the one `git fetch` uses.\n> \n> I think there was some bikeshedding around that time. I share the\n> sentiment, but worry about \"core\" over-configuring such a\n> thing.\n\nI don't see a need for core.defaultRemote, but I don't see a need for\ncheckout.defaultRemote either.\n\nJust have `checkout.autoUpstream = true` and hardcode *both* to \"origin\".\n\n> >> * commit.verbose=true: so you know what you're looking at in doing in\n> >> \"git commit --amend\".\n> >\n> > Aha! My alias had `commit -v` but I would want this on all commit\n> > commands.\n> >\n> > Moreover, I was thinking on suggesting this by default. Who would it\n> > hurt?\n> \n> E.g. \"git rebase -i\" with \"reword\" now becomes a lot more verbose, I\n> think it's a feature, but others might disagree.\n> \n> It also exposes various edge cases around our parsing of the diff\n> v.s. commit message content in our apply.c etc. code, e.g. say you want\n> to blindly search-replace \"diff\" with \"difference\" in your commit\n> messages. You'll now change the \"diff --git\" line to \"difference --git\",\n> and now \"commit\" won't detect that it's the patch part anymore, and\n> merge that diff into your commit message itself.\n> \n> I can't remember if we pick up on \"diff --git\" exactly, IIRC, but\n> anyway, whatever part of the format you need to screw with, the point\n> stands. I've run into mistakes like that in the past, one recently made\n> it to this ML.\n\nI've personally never have had a problem with it.\n\nSure, it *might* have some issues, but any change does. That's not a\nvery strong arugment against making it the default.\n\n> >> * grep.patternType=perl: Another personal soap box (but really, BRE\n> >> anywhere sucks).\n> >\n> > Nice. `git grep` is the #2 command I use the most, and I often need to\n> > specify another regexp because the basic one doesn't understand what I'm\n> > trying to do.\n> \n> Yeah, it should be at least ERE by default, Something for Git v3.0 ...?\n> \n> >> I also have a bunch of aliases that would not be useful to a general\n> >> audience, but which I find I can't live without, some of the most\n> >> commonly used ones:\n> >> \n> >> # Log with \"less\" n/p already going to the next/prev commit\n> >> log-psfd = \"!f() { PAGER=\\\"less -p'^commit'\\\" git log -p --stat --full-diff $@; }; f\"\n> >\n> > Very neat.\n> \n> I think similar to your \"git help xyz\" patches having coloring, we\n> really should consider things like that by default knowing that we're\n> invoking \"less\". I.e. if we got over the notion that our job is just to\n> throw data over the wall to \"man\" or the pager without any further\n> tweaking or integration.\n\nPerhaps. I think defaults should be tried-and-true. Only after a\nconsiderable number of people have tried them should they become\ndefault.\n\nI have no problem with something like the above being a default, but\nonly when the user has specified these kinds of features.\n\nMaybe with\n\n [core]\n mode = fancy\n\n> >> Similarly rebase is \"r\", \"--interactive\" is \"ri\", \"--abort\", and\n> >> \"--continue\" are \"ra\" and \"rc\".\n> >\n> > I have almost the same, except rbi, rbc, and rba. My 'r' is reset, but\n> > since I use rebase more often I guess I should switch them up.\n> >\n> > Theres are a couple of mine:\n> >\n> > advance = merge --ff-only\n> > undo = reset --hard @{1}\n> > \n> >> If anyone's interested in the rest / full set:\n> >> https://github.com/avar/dotfiles/blob/master/.gitconfig\n> >\n> > Is thata private repo?\n> >\n> > Here are mine:\n> >\n> > https://github.com/felipec/dotfiles/blob/master/.gitconfig\n> \n> Yes, it was private[1]. I've made it public again.\n> \n> 1. It used to be public, but then the security/auditing people at an\n> ex-job kept pestering me about me hardcoding über-secret company data\n> in public GitHub repos.\n> \n> They didn't find questions like \"uh, you mean this information we\n> advertise in an MX lookup to our public nameservers?\", or \"yes,\n> that's my company E-Mail address in a config file, my co-workers have\n> the same info on linkedin\" all that convincing. Anyway, it's back now\n> :)\n\nYeah, it's surpsingly difficult to convince some people of the most\nobvious things. I rather have a private branch on my dotfiles, where I\ndon't have anything sensitive really, just stuff I'm sure others won't\nfind useful.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"426405","messageId":"3edd4518-00bd-6227-54e5-e546fd6b849b@gmail.com","threadId":"55814","inReplyTo":"87tume6g0g.fsf@evledraar.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-06-04T10:24:14Z","receivedAt":"2021-06-04T10:24:26Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Ævar\nOn 03/06/2021 17:44, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Thu, Jun 03 2021, Phillip Wood wrote:\n> \n>> Hi Ævar\n>>\n>> On 03/06/2021 13:31, Ævar Arnfjörð Bjarmason wrote:\n>>> On Thu, Jun 03 2021, Felipe Contreras wrote:\n>>>\n>>>> Ævar Arnfjörð Bjarmason wrote:\n>>>>> So I skipped the \"disable most config\", but for what it's worth I think\n>>>>> I'd miss these the most, I couldn't pick just N favorites, sorry:\n>>>>>\n>>>>> * diff.colorMoved=true: super useful, but I'd be vary of turning it on\n>>>>> by default in its current form. E.g. on gcc.git's changelog files it\n>>>>> has really pathological performance characteristics.\n>>\n>> Would you be able say a bit more about this so I can try and reproduce\n>> it please. I'm working on some patches [1] to improve the performance\n>> of `diff --color-moved` and `diff --color-moved-ws` and it would be\n>> good to test them on a problematic repo. At the moment I diffing two\n>> releases of git to test performance on a large diff. I just cloned the\n>> last 18 months of gcc.git and Changelog seems to just be appended to.\n> \n> I misremembered the gcc.git ChangeLog issue, sorry. That's about\n> something else entirely.\n> \n> The issue with the color moved code can just be reproduced on most large\n> diffs, e.g. on git.git:\n> \n> $ time git diff --color-moved=true v2.25.0..v2.30.0 >/dev/null\n> real 0m10.112s\n> $ time git diff --color-moved=false v2.25.0..v2.30.0 >/dev/null\n> real 0m0.939s\n\n\"Big diffs are slow with --color-moved\" is the problem I've been \nfocusing on. With my patches I see the time for --color-moved=true go \ndown from 16s to 4.3s for that example. --color-moved=false takes 0.8s \nso the --color-moved=true is still quite a bit slower but it's not as \nbad. --color-moved-ws=allow-indentation-change goes from 8 minutes(!) to \n6 seconds. I'm seeing a slight (few percent) slowdown for `git log \n--patch --no-merges -n1000` though which I'd like to avoid.\n\n> So 10x slower, and e.g. diffing from v2.22.0 makes it 25s and 1.1s,\n> respectively.\n>\n> In some sense that slowness is expected, it simly takes time to compute\n> this. I think for turning it on by default we should have something like\n> the diff.renameLimit, and change the default to some \"auto\" that would\n> punt out if it was taking too long to compute.\n> \n> I run with it by default so this doesn't bother me, but I think it's\n> probably a semi-common use-case of some people to e.g. diff the last N\n> releases of Linux, and then use their pager to search around in the\n> diff.\n\nYeah I can see people doing that.\n\n> We don't want commands like that to take 25s instead of 1s, but I think\n> it would be fine (and we should) warn that we aborted on the color move\n> if it's otherwise the default.\n> \n> Otherwise it'll take 1s, and if you normally depend on it you'll\n> conclude that some code you're looking at wasn't moved, which would also\n> suck, better to punt on it and warn, just like the diff.renameLimit.\n\nThat's a nice idea, one other thought I had was to fall back to just \nlooking for moved lines within the same file - that would be much faster \non a large diff with lots of files but maybe it is confusing to \nhighlight only some of the moved lines when there are interfile as well \nas intrafile moves.\n\nBest Wishes\n\nPhillip\n\n> \n>>>> Very nice! I didn't know about it. I'll pick it for my third day.\n>>> It makes patch review a lot easier, and also integrates nicely with\n>>> -w.\n>>\n>> I find --color-moved-ws=allow-indentation-change helpful as well (it\n>> is quite a bit slower at the moment but I have some patches to bring\n>> it up to the speed of the other --color-moved modes.\n>>\n>> [1] https://github.com/phillipwood/git/tree/wip/diff-color-moved-tweaks\n> \n> Nice, I didn't know about that option. Will try it.\n> \n\n"},{"id":"429021","messageId":"60dee69fb7cc7_2964b208fb@natae.notmuch","threadId":"55814","inReplyTo":"87zgw75dyi.fsf@evledraar.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T10:12:47Z","receivedAt":"2021-07-02T10:12:53Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Thu, Jun 03 2021, Felipe Contreras wrote:\n> > Ævar Arnfjörð Bjarmason wrote:\n\n> >> We could then just extend the include syntax rather easily to include\n> >> \"libraries\", which would be like the current include.path, but would\n> >> understand a library:: prefix (better name bikeshedding welcome). We'd\n> >> then just ship these in /usr/share/git-core/config/includes or whatever,\n> >> e.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg\n> >\n> > I wouldn't be against some some suggested defaults, but *in addition* to\n> > some hardcoded default aliases that are documented.\n> \n> I'm talking about in terms of the flexibility of implementation of\n> on-by-default defaults. We could implement it as I suggested and then\n> just have a core.defaultIncludes, which would by default be set to\n> git::aliases/svn-like.cfg or whatever, i.e. equivalent to:\n> \n> [core]\n> defaultIncludes = \"git::default.cfg\"\n> \n> Which itself would include a\n> /usr/share/git-core/config/includes/default.cfg which would do:\n\nI really gave this a try, but the problem is that git doesn't even have\na stardard location to install shared files.\n\nI started with $sharedir, but that's not git-specific. Then I added\n$gitsharedir which required a bunch of changes to the Makefile, and\neventually I decided against it.\n\nWe don't have standard location for shared files. Period.\n\n> In a way this is total bikeshedding, I just think it's worth doing it\n> this way up-front.\n\nYes, maybe so, but git infraestructure is completely unprepared for that\n(at this point).\n\nSo I just decied to hard-code them [1]\n\n[1] https://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras"},{"id":"429033","messageId":"87zgv59bm8.fsf@evledraar.gmail.com","threadId":"55814","inReplyTo":"60dee69fb7cc7_2964b208fb@natae.notmuch","subject":"Re: The git spring cleanup challenge","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-07-02T11:43:52Z","receivedAt":"2021-07-02T11:52:20Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Jul 02 2021, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> On Thu, Jun 03 2021, Felipe Contreras wrote:\n>> > Ævar Arnfjörð Bjarmason wrote:\n>\n>> >> We could then just extend the include syntax rather easily to include\n>> >> \"libraries\", which would be like the current include.path, but would\n>> >> understand a library:: prefix (better name bikeshedding welcome). We'd\n>> >> then just ship these in /usr/share/git-core/config/includes or whatever,\n>> >> e.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg\n>> >\n>> > I wouldn't be against some some suggested defaults, but *in addition* to\n>> > some hardcoded default aliases that are documented.\n>> \n>> I'm talking about in terms of the flexibility of implementation of\n>> on-by-default defaults. We could implement it as I suggested and then\n>> just have a core.defaultIncludes, which would by default be set to\n>> git::aliases/svn-like.cfg or whatever, i.e. equivalent to:\n>> \n>> [core]\n>> defaultIncludes = \"git::default.cfg\"\n>> \n>> Which itself would include a\n>> /usr/share/git-core/config/includes/default.cfg which would do:\n>\n> I really gave this a try, but the problem is that git doesn't even have\n> a stardard location to install shared files.\n>\n> I started with $sharedir, but that's not git-specific. Then I added\n> $gitsharedir which required a bunch of changes to the Makefile, and\n> eventually I decided against it.\n>\n> We don't have standard location for shared files. Period.\n>\n>> In a way this is total bikeshedding, I just think it's worth doing it\n>> this way up-front.\n>\n> Yes, maybe so, but git infraestructure is completely unprepared for that\n> (at this point).\n>\n> So I just decied to hard-code them [1]\n>\n> [1] https://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com/\n\nFWIW I only saw this reply after I replied in that thread\n... referencing this one.\n\nI haven't tried, but I'd think it wouldn't be a big change. You're\ninjecting alias.* config directly, you could just inject an\ninclude.path=* in the relevant part of the config machinery instead.\n\nWe'd need a new verb like gitdir:* and onbranch:*, maybe system:* or\ngit:*, we'd then search system:foo.cfg for those relative to our libexec\nor /usr/share data, e.g. /usr/lib/git-core/config/foo.cfg\n\nWe could then carry those in includes/* in the git.git repo, and to\naddress the \"let's make sure they're there\" have a trivial build step\nlike the command-list.h to build those into a C object. I.e. dog-food on\nour own build process and run `git config -f -l -z` for each one,\nmunge that and spew it into a *.c\nfile. I.e. include/aliases/svn-like.cfg or whatever.\n\nThen when we can't find a system:* (or whatever it's called)\nhandle_path_include() we'd consult that list of fallbacks.\n\nI'm not saying it's trivial, just that I think in practice building\nconsensus for a \"one blessed list of hardcoded aliases\" is going to be a\nvery tough sell, and making it optional/configurable/pluggable might\nmake that sell a lot easier.\n"},{"id":"429078","messageId":"60df8b2a7e982_2eee2088@natae.notmuch","threadId":"55814","inReplyTo":"87zgv59bm8.fsf@evledraar.gmail.com","subject":"Re: The git spring cleanup challenge","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-02T21:54:50Z","receivedAt":"2021-07-02T21:54:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Fri, Jul 02 2021, Felipe Contreras wrote:\n> \n> > Ævar Arnfjörð Bjarmason wrote:\n> >> On Thu, Jun 03 2021, Felipe Contreras wrote:\n> >> > Ævar Arnfjörð Bjarmason wrote:\n> >\n> >> >> We could then just extend the include syntax rather easily to include\n> >> >> \"libraries\", which would be like the current include.path, but would\n> >> >> understand a library:: prefix (better name bikeshedding welcome). We'd\n> >> >> then just ship these in /usr/share/git-core/config/includes or whatever,\n> >> >> e.g. /usr/share/git-core/config/includes/aliases/svn-like.cfg\n> >> >\n> >> > I wouldn't be against some some suggested defaults, but *in addition* to\n> >> > some hardcoded default aliases that are documented.\n> >> \n> >> I'm talking about in terms of the flexibility of implementation of\n> >> on-by-default defaults. We could implement it as I suggested and then\n> >> just have a core.defaultIncludes, which would by default be set to\n> >> git::aliases/svn-like.cfg or whatever, i.e. equivalent to:\n> >> \n> >> [core]\n> >> defaultIncludes = \"git::default.cfg\"\n> >> \n> >> Which itself would include a\n> >> /usr/share/git-core/config/includes/default.cfg which would do:\n> >\n> > I really gave this a try, but the problem is that git doesn't even have\n> > a stardard location to install shared files.\n> >\n> > I started with $sharedir, but that's not git-specific. Then I added\n> > $gitsharedir which required a bunch of changes to the Makefile, and\n> > eventually I decided against it.\n> >\n> > We don't have standard location for shared files. Period.\n> >\n> >> In a way this is total bikeshedding, I just think it's worth doing it\n> >> this way up-front.\n> >\n> > Yes, maybe so, but git infraestructure is completely unprepared for that\n> > (at this point).\n> >\n> > So I just decied to hard-code them [1]\n> >\n> > [1] https://lore.kernel.org/git/20210702100506.1422429-1-felipe.contreras@gmail.com/\n> \n> FWIW I only saw this reply after I replied in that thread\n> ... referencing this one.\n> \n> I haven't tried, but I'd think it wouldn't be a big change.\n\nAs I explaind the problem is that the build infraestructure is\ncompletely unprepared to install files in /usr/share.\n\nGo ahead and try to add a simple text file to the distribution.\n\nAre you going to put it under /usr/share/git-core? Where are you going\nto add it in the git tree? What target is going to install it?\n\n> You're injecting alias.* config directly, you could just inject an\n> include.path=* in the relevant part of the config machinery instead.\n> \n> We'd need a new verb like gitdir:* and onbranch:*, maybe system:* or\n> git:*, we'd then search system:foo.cfg for those relative to our libexec\n> or /usr/share data, e.g. /usr/lib/git-core/config/foo.cfg\n> \n> We could then carry those in includes/* in the git.git repo, and to\n> address the \"let's make sure they're there\" have a trivial build step\n> like the command-list.h to build those into a C object. I.e. dog-food on\n> our own build process and run `git config -f -l -z` for each one,\n> munge that and spew it into a *.c\n> file. I.e. include/aliases/svn-like.cfg or whatever.\n> \n> Then when we can't find a system:* (or whatever it's called)\n> handle_path_include() we'd consult that list of fallbacks.\n> \n> I'm not saying it's trivial, just that I think in practice building\n> consensus for a \"one blessed list of hardcoded aliases\" is going to be a\n> very tough sell, and making it optional/configurable/pluggable might\n> make that sell a lot easier.\n\nI know, I do see value in this approach, which is why I tried. But when\nI saw I was making more changes to the Makefile than the code I decided\nto stop.\n\nMoreover, it makes little sense to implement this perfectly if Junio is\nsimply going to reject it all.\n\nMaybe once we have the \"extra\" directory it would be more straightforward.\n\n-- \nFelipe Contreras"}]}