{"thread":{"id":"57610","subject":"contrib/vscode/: debugging with vscode and gdb","startedAt":"2022-03-24T08:17:07Z","lastAt":"2022-04-07T20:46:25Z","messageCount":24,"participants":["Jonathan Bressat","Derrick Stolee","Matthieu Moy","Guillaume Cogoni","COGONI Guillaume","Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"452101","messageId":"CANteD_wDSRmwLQiYV1x133WEtVaRK__c584E3CbXN1tPOquitg@mail.gmail.com","threadId":"57610","inReplyTo":null,"subject":"contrib/vscode/: debugging with vscode and gdb","fromName":"Jonathan Bressat","fromEmail":"git.jonathan.bressat@gmail.com","sentAt":"2022-03-24T08:16:48Z","receivedAt":"2022-03-24T08:17:07Z","isPatch":false,"sender":{"key":"git.jonathan.bressat@gmail.com","avatar":null},"body":"Hello\nIn contrib/vscode/ the script init.sh create launch.json with the\noption \"external console\" to true but actually this option make gdb\ndidn't work so we passed to false and then it works.\nIs there any reasons why it is set to true, do we not use this properly ?\nThen would it be nice to correct it in contrib/vscode and to talk\nabout it in that doc : https://git-scm.com/docs/MyFirstContribution ?\n\nThanks,\n\nGuillaume COGONI and\nJonathan BRESSAT\n"},{"id":"452260","messageId":"f6afa542-cd97-2af9-a07f-6c2a3721a200@github.com","threadId":"57610","inReplyTo":"CANteD_wDSRmwLQiYV1x133WEtVaRK__c584E3CbXN1tPOquitg@mail.gmail.com","subject":"Re: contrib/vscode/: debugging with vscode and gdb","fromName":"Derrick Stolee","fromEmail":"derrickstolee@github.com","sentAt":"2022-03-25T13:19:42Z","receivedAt":"2022-03-25T13:19:48Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 3/24/2022 4:16 AM, Jonathan Bressat wrote:\n> Hello\n> In contrib/vscode/ the script init.sh create launch.json with the\n> option \"external console\" to true but actually this option make gdb\n> didn't work so we passed to false and then it works.\n> Is there any reasons why it is set to true, do we not use this properly ?\n> Then would it be nice to correct it in contrib/vscode and to talk\n> about it in that doc : https://git-scm.com/docs/MyFirstContribution ?\n\nHi Jonathan and Guillaume,\n\nI use VS Code to work on Git (using Remote SSH from a Windows machine\nto a Linux machine) but I've always used command-line gdb for debugging.\n\nHowever, your request here got me interested. I confirmed that running\nthe debugger from the VS Code UI did not show any output or show that\na breakpoint was hit. Performing the update you recommend made the\ndebuggin UI populate with all the necessary info (stack trace, variables,\nshowing the breakpoint line in the editor).\n\nHere is a patch that makes the change as you suggest. I tried to research\nthe setting appropriately, so please let me know if there is anything you\nthink is incorrect here.\n\nThanks,\n-Stolee\n\n--- >8 ---\n\nFrom b053b797cf8585d2b0212cd2576fe05c2d1a5432 Mon Sep 17 00:00:00 2001\nFrom: Derrick Stolee \nDate: Fri, 25 Mar 2022 09:07:11 -0400\nSubject: [PATCH] contrib/vscode: fix interaction with UI debugger\n\nThe contrib/vscode/init.sh script helps Git developers using Visual\nStudio Code to hook up the proper settings to work on Git using the UI\nfeatures of that editor environment. This should include the debugger\nintegration, but that is currently broken.\n\nOne thing this script does is create a .vscode/launch.json file, which\nprovides the information for how VS Code should launch the built\nexecutable. This defaults to the Git executable at the root of the\nrepository (with no arguments). Among the initial settings, the\n\"externalConsole\" setting is set to \"true\". This has been the case since\nthe script was created in 54c06c6013 (contrib: add a script to\ninitialize VS Code configuration, 2018-07-30).\n\nJonathan and Guillame reported that flipping this setting to \"false\"\nallows the VS Code debugger to work with Git. I verified that the\ndebugger did not work by default but now does with this change.\n\nThe VS Code reference [1] mentions that this setting is only used when\ndebugging, so should not affect the \"Run Without Debugging\" feature.\nOther than making the UI debugger work, this will also change the Git\noutput to appear in the \"Debug Console\" tab instead of a new window.\n\n[1] https://code.visualstudio.com/docs/cpp/launch-json-reference\n\nIn cases such as using the Remote SSH capability, this setting is\nnecessary to have any success executing Git via the \"Run\" menu, since\nthe external console is not visible at all from the VS Code window.\n\nReported-by: Jonathan Bressat \nReported-by: Cogoni Guillaume \nSigned-off-by: Derrick Stolee \n---\n contrib/vscode/init.sh | 2 +-\n t/test-lib-functions.sh | 34 ----------------------------------\n 2 files changed, 1 insertion(+), 35 deletions(-)\n\ndiff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\nindex 27de94994b5..0b7ebc12668 100755\n--- a/contrib/vscode/init.sh\n+++ b/contrib/vscode/init.sh\n@@ -271,7 +271,7 @@ cat >.vscode/launch.json.new < ... < \n-#\n-# For example, to look for an invocation of \"git pack-objects\"\n-# with the \"--honor-pack-keep\" argument, use\n-#\n-#\tGIT_TRACE2_EVENT=event.log git repack ... &&\n-#\ttest_subcommand git pack-objects --honor-pack-keep On 3/25/22 14:19, Derrick Stolee wrote:\n> \n>> Jonathan and Guillame reported that flipping this setting to \"false\"\n>> allows the VS Code debugger to work with Git. I verified that the\n>> debugger did not work by default but now does with this change.\n> \n> FYI, I got the same problem, and I can reproduce the issue on a hello world program, so \"externalConsole\": true, is broken at least for me regardless of the Git codebase.\n> \n> I couldn't understand what exactly the option was supposed to do. If I understand correctly, it should launch another window to show the git program output, but I don't know which window actually (xterm? x-terminal-emulator? a terminal program that isn't installed on my system?).\n> \n>>   contrib/vscode/init.sh  |  2 +-\n>>   t/test-lib-functions.sh | 34 ----------------------------------\n> \n> I guess the test-lib-functions.sh part is a leftover from another work?\n\nWhoops! Yes I was in the wrong worktree.\n\n>> -            \"externalConsole\": true,\n>> +            \"externalConsole\": false,\n> I'd actually remove the line completely, to mean \"let VSCode decide what to do\", i.e. either VSCode's default, or the user's configuration (\"launch\" section in settings.json, see e.g. https://code.visualstudio.com/docs/getstarted/settings ). If some user has a non-broken externalConsole: true VSCode and likes this behavior, then the best place to configure it is in a user-wide config file IHMO.\n\nI confirmed that deleting the line works just fine.\n\nHere's a better patch without the bogus extra changes.\n\n--- >8 ---\n\nFrom 8d8ac565a9c6631a509f301e7719692bd781f8d2 Mon Sep 17 00:00:00 2001\nFrom: Derrick Stolee \nDate: Fri, 25 Mar 2022 09:07:11 -0400\nSubject: [PATCH] contrib/vscode: fix interaction with UI debugger\n\nThe contrib/vscode/init.sh script helps Git developers using Visual\nStudio Code to hook up the proper settings to work on Git using the UI\nfeatures of that editor environment. This should include the debugger\nintegration, but that is currently broken.\n\nOne thing this script does is create a .vscode/launch.json file, which\nprovides the information for how VS Code should launch the built\nexecutable. This defaults to the Git executable at the root of the\nrepository (with no arguments). Among the initial settings, the\n\"externalConsole\" setting is set to \"true\". This has been the case since\nthe script was created in 54c06c6013 (contrib: add a script to\ninitialize VS Code configuration, 2018-07-30).\n\nJonathan and Guillame reported that flipping this setting to \"false\"\nallows the VS Code debugger to work with Git. Matthieu pointed out that\nthis is the default, so we can leave it out of the file completely and\nlet a user modify that themselves if they want. I validated that both\nthe \"false\" setting and removing the line both work.\n\nThe VS Code reference [1] mentions that this setting is only used when\ndebugging, so should not affect the \"Run Without Debugging\" feature.\nOther than making the UI debugger work, this will also change the Git\noutput to appear in the \"Debug Console\" tab instead of a new window.\n\n[1] https://code.visualstudio.com/docs/cpp/launch-json-reference\n\nIn cases such as using the Remote SSH capability, this setting is\nnecessary to have any success executing Git via the \"Run\" menu, since\nthe external console is not visible at all from the VS Code window.\n\nReported-by: Jonathan Bressat \nReported-by: Cogoni Guillaume \nHelped-by: Matthieu Moy \nSigned-off-by: Derrick Stolee \n---\n contrib/vscode/init.sh | 1 -\n 1 file changed, 1 deletion(-)\n\ndiff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\nindex 27de94994b5..f139fd86444 100755\n--- a/contrib/vscode/init.sh\n+++ b/contrib/vscode/init.sh\n@@ -271,7 +271,6 @@ cat >.vscode/launch.json.new < Jonathan and Guillame reported that flipping this setting to \"false\"\n> allows the VS Code debugger to work with Git. I verified that the\n> debugger did not work by default but now does with this change.\n\nFYI, I got the same problem, and I can reproduce the issue on a hello \nworld program, so \"externalConsole\": true, is broken at least for me \nregardless of the Git codebase.\n\nI couldn't understand what exactly the option was supposed to do. If I \nunderstand correctly, it should launch another window to show the git \nprogram output, but I don't know which window actually (xterm? \nx-terminal-emulator? a terminal program that isn't installed on my system?).\n\n> contrib/vscode/init.sh | 2 +-\n> t/test-lib-functions.sh | 34 ----------------------------------\n\nI guess the test-lib-functions.sh part is a leftover from another work?\n\n> - \"externalConsole\": true,\n> + \"externalConsole\": false,\nI'd actually remove the line completely, to mean \"let VSCode decide what \nto do\", i.e. either VSCode's default, or the user's configuration \n(\"launch\" section in settings.json, see e.g. \nhttps://code.visualstudio.com/docs/getstarted/settings ). If some user \nhas a non-broken externalConsole: true VSCode and likes this behavior, \nthen the best place to configure it is in a user-wide config file IHMO.\n\nCheers,\n\n-- \nMatthieu Moy\nhttps://matthieu-moy.fr/\n"},{"id":"452408","messageId":"CANteD_yZ8de2i54EUWW=d6eVzpiKm5NNHGVEKrXOmo5KXnXUVQ@mail.gmail.com","threadId":"57610","inReplyTo":"c1f255d7-6637-b6ac-0a64-1f64404a6f6c@github.com","subject":"Re: contrib/vscode/: debugging with vscode and gdb","fromName":"Jonathan Bressat","fromEmail":"git.jonathan.bressat@gmail.com","sentAt":"2022-03-26T14:11:07Z","receivedAt":"2022-03-26T14:11:22Z","isPatch":false,"sender":{"key":"git.jonathan.bressat@gmail.com","avatar":null},"body":"On 3/25/2022 2:27 PM, Matthieu Moy wrote:\n\n> I couldn't understand what exactly the option was supposed to do. If I\n> understand correctly, it should launch another window to show the git\n> program output, but I don't know which window actually (xterm?\n> x-terminal-emulator? a terminal program that isn't installed on my system?).\n\nIn VS Code settings, it seems to be x-terminal-emulator.\n\n\nOn 3/25/2022 8:01 PM, Derrick Stolee wrote :\n> >> - \"externalConsole\": true,\n> >> + \"externalConsole\": false,\n> I'd actually remove the line completely, to mean \"let VSCode decide what to do\", i.e. either VSCode's default, or the user's configuration (\"launch\" section in settings.json, see e.g. https://code.visualstudio.com/docs/getstarted/settings ). If some user has a > non-broken externalConsole: true VSCode and likes this behavior, then the best place to configure it is in a user-wide config file IHMO.\n>\n> I confirmed that deleting the line works just fine.\n\nYes, we agree with both of you, remove the line completly is better\nbecause it let the user choices his preferences.\nAnd it also work for us.\n\n> Reported-by: Jonathan Bressat \n> Reported-by: Cogoni Guillaume \n> Helped-by: Matthieu Moy \n> Signed-off-by: Derrick Stolee \n> ---\n> contrib/vscode/init.sh | 1 -\n> 1 file changed, 1 deletion(-)\n>\n> diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\n> index 27de94994b5..f139fd86444 100755\n> --- a/contrib/vscode/init.sh\n> +++ b/contrib/vscode/init.sh\n> @@ -271,7 +271,6 @@ cat >.vscode/launch.json.new < \"stopAtEntry\": false,\n> \"cwd\": \"\\${workspaceFolder}\",\n> \"environment\": [],\n> - \"externalConsole\": true,\n> \"MIMode\": \"gdb\",\n> \"miDebuggerPath\": \"$GDBPATH\",\n> \"setupCommands\": [\n> --\n> 2.35.1.138.gfc5de29e9e6\n>\n>\n\nhttps://code.visualstudio.com/docs/editor/debugging\nhttps://code.visualstudio.com/docs/getstarted/settings\nMaybe, It would be nice to add these two links in\ncontrib/vscode/readme.md, this may be relevant to\nhelp new users that want to use vscode debugger. And add some explanations\nlike \"How to use it\".\n\nExcept that, your patch sounds good for us.\n\nThanks,\n\nGuillaume and Jonathan.\n"},{"id":"453006","messageId":"CAA0Qn1tscbh-jzRDxL-9heMA4Nu8Z=7ssuT6cTeKGB_yvKgwBA@mail.gmail.com","threadId":"57610","inReplyTo":"CANteD_yZ8de2i54EUWW=d6eVzpiKm5NNHGVEKrXOmo5KXnXUVQ@mail.gmail.com","subject":"Re: contrib/vscode/: debugging with vscode and gdb","fromName":"Guillaume Cogoni","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-03T20:18:19Z","receivedAt":"2022-04-03T20:18:36Z","isPatch":false,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"Hello,\n\nWe don't know if we can revive this topic, but we still think that\nit's a good idea\nto talk more about \"how it can be useful to use the debugging tool that gives\nVS Code\".\n\nSo, we make a patch about it.\nWe retrieve what Derrick Stolee did and add what we said in our previous mail.\n\nThanks,\nCogoni Guillaume and Jonathan Bressat\n\n--------------------->8-----------------------------------\n\nSubject: [PATCH 0/1] contrib/vscode/: debugging with VS Code and gdb\nCOGONI Guillaume (1):\ncontrib/vscode/: debugging with VS Code and gdb\n\n| Documentation/MyFirstContribution.txt | 12 ++++++++++++\n| contrib/vscode/README.md | 5 +++++\n| contrib/vscode/init.sh | 1 -\n| 3 files changed, 17 insertions(+), 1 deletion(-)\n\n-- \n2.25.1\n\nDate: Sun, 3 Apr 2022 21:47:02 +0200\nSubject: [PATCH 1/1] contrib/vscode/: debugging with VS Code and gdb\n\nRemove \"externalConsole\" line in contrib/vscode/init.sh because it\nseems to not work for everyone, and after a discussion with Matthieu\nMoy and Derrick Stolee, we agreed that it is better to let the user choose\nwhat to do with this line (Add his own configuration).\n\nAdd useful links in contrib/vscode/README.md to help the user to\nconfigure his VS Code and how to use the debugging feature.\n\nAdd a mention to the README in Documentation/MyFirstContribution.txt\nand a part \"To convince a newcomer that VS Code can help him\".\n\nSigned-off-by: COGONI Guillaume \nCo-authored-by: BRESSAT Jonathan \nHelped-by: Matthieu Moy \nHelped-by: Derrick Stolee \n---\nDocumentation/MyFirstContribution.txt | 12 ++++++++++++\ncontrib/vscode/README.md | 5 +++++\ncontrib/vscode/init.sh | 1 -\n3 files changed, 17 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt\nb/Documentation/MyFirstContribution.txt\nindex 63a2ef5449..97f53f536d 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1265,3 +1265,15 @@ against the appropriate GitGitGadget/Git branch.\nIf you're using `git send-email`, you can use it the same way as before, but you\nshould generate your diffs from `..` and base your work on\n`` instead of `master`.\n+\n+[[Bonus-useful-tools]]\n+== Bonus - useful tools\n+\n+=== VS Code\n+\n+To see \"how to use VS Code\" read contrib/vscode/README.md.\n+If you want to try to understand \"how git works internally\", the debugging\n+feature of VS Code can help you. It will not give you all the keys to\nfully understand it, but\n+it can give you an idea of \"how the information travels inside the code\".\n+It can help you to isolate some parts of code, with this you are able\n+to ask more precise questions when you are stuck. (See getting-help sections).\n\\ No newline at end of file\n\ndiff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\nindex 8202d62035..a416a752c1 100644\n--- a/contrib/vscode/README.md\n+++ b/contrib/vscode/README.md\n@@ -8,6 +8,11 @@ code editor which runs on your desktop and is available for\n[Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\nit has [support for C/C++ via an\nextension](https://github.com/Microsoft/vscode-cpptools).\n+To understand \"how works the debugging part\" read:\n+[Help with the debugging\npart](https://code.visualstudio.com/docs/editor/debugging)\n+To get help about \"how to personalize your settings\" read:\n+[How to set up your\nsettings](https://code.visualstudio.com/docs/getstarted/settings)\n+\nTo start developing Git with VS Code, simply run the Unix shell script called\n`init.sh` in this directory, which creates the configuration files in\n`.vscode/` that VS Code consumes. `init.sh` needs access to `make` and `gcc`,\n\ndiff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\nindex 27de94994b..f139fd8644 100755\n--- a/contrib/vscode/init.sh\n+++ b/contrib/vscode/init.sh\n@@ -271,7 +271,6 @@ cat >.vscode/launch.json.new < wrote:\n>\n> On 3/25/2022 2:27 PM, Matthieu Moy wrote:\n>\n> > I couldn't understand what exactly the option was supposed to do. If I\n> > understand correctly, it should launch another window to show the git\n> > program output, but I don't know which window actually (xterm?\n> > x-terminal-emulator? a terminal program that isn't installed on my system?).\n>\n> In VS Code settings, it seems to be x-terminal-emulator.\n>\n>\n> On 3/25/2022 8:01 PM, Derrick Stolee wrote :\n> > >> - \"externalConsole\": true,\n> > >> + \"externalConsole\": false,\n> > I'd actually remove the line completely, to mean \"let VSCode decide what to do\", i.e. either VSCode's default, or the user's configuration (\"launch\" section in settings.json, see e.g. https://code.visualstudio.com/docs/getstarted/settings ). If some user has a > non-broken externalConsole: true VSCode and likes this behavior, then the best place to configure it is in a user-wide config file IHMO.\n> >\n> > I confirmed that deleting the line works just fine.\n>\n> Yes, we agree with both of you, remove the line completly is better\n> because it let the user choices his preferences.\n> And it also work for us.\n>\n> > Reported-by: Jonathan Bressat \n> > Reported-by: Cogoni Guillaume \n> > Helped-by: Matthieu Moy \n> > Signed-off-by: Derrick Stolee \n> > ---\n> > contrib/vscode/init.sh | 1 -\n> > 1 file changed, 1 deletion(-)\n> >\n> > diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\n> > index 27de94994b5..f139fd86444 100755\n> > --- a/contrib/vscode/init.sh\n> > +++ b/contrib/vscode/init.sh\n> > @@ -271,7 +271,6 @@ cat >.vscode/launch.json.new < > \"stopAtEntry\": false,\n> > \"cwd\": \"\\${workspaceFolder}\",\n> > \"environment\": [],\n> > - \"externalConsole\": true,\n> > \"MIMode\": \"gdb\",\n> > \"miDebuggerPath\": \"$GDBPATH\",\n> > \"setupCommands\": [\n> > --\n> > 2.35.1.138.gfc5de29e9e6\n> >\n> >\n>\n> https://code.visualstudio.com/docs/editor/debugging\n> https://code.visualstudio.com/docs/getstarted/settings\n> Maybe, It would be nice to add these two links in\n> contrib/vscode/readme.md, this may be relevant to\n> help new users that want to use vscode debugger. And add some explanations\n> like \"How to use it\".\n>\n> Except that, your patch sounds good for us.\n>\n> Thanks,\n>\n> Guillaume and Jonathan.\n"},{"id":"453105","messageId":"6f4b924d-0a13-b267-6766-a3620936b686@univ-lyon1.fr","threadId":"57610","inReplyTo":"7b139f2c480e4ebc8dc6615b44cd5f24@SAMBXP02.univ-lyon1.fr","subject":"Re: contrib/vscode/: debugging with vscode and gdb","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@univ-lyon1.fr","sentAt":"2022-04-05T09:43:37Z","receivedAt":"2022-04-05T09:53:23Z","isPatch":false,"sender":{"key":"matthieu.moy@univ-lyon1.fr","avatar":"https://gravatar.com/avatar/8ab83b763226bd297b59ddd1463a8bfc852924577191233f73a953b86888fe0c?d=mp&s=160"},"body":"On 4/3/22 22:18, Guillaume Cogoni wrote:\n> Hello,\n> \n> We don't know if we can revive this topic, but we still think that\n> it's a good idea\n> to talk more about \"how it can be useful to use the debugging tool that gives\n> VS Code\".\n> \n> So, we make a patch about it.\n> We retrieve what Derrick Stolee did and add what we said in our previous mail.\n> \n> Thanks,\n> Cogoni Guillaume and Jonathan Bressat\n> \n> --------------------->8-----------------------------------\n> \n> Subject: [PATCH 0/1] contrib/vscode/: debugging with VS Code and gdb\n> COGONI Guillaume (1):\n> contrib/vscode/: debugging with VS Code and gdb\n\nHow did you generate this patch? It doesn't apply with 'git am', I \nsuspect you copy-pasted incorrectly into your mailer. Using 'git \nsend-email' helps sending properly formatted patches.\n\n > Remove \"externalConsole\" line in contrib/vscode/init.sh because it\n > seems to not work for everyone, and after a discussion with Matthieu\n > Moy and Derrick Stolee, we agreed that it is better to let the user \nchoose\n > what to do with this line\n\nI usually explain the problem first, and then the solution.\n\nThe externalConsole=true setting is broken for many users (launching the \ndebugger with such setting results in VS Code waiting forever without \nactually starting the debugger). Also, this setting is a matter of user \npreference, and is arguably better set in a \"launch\" section in the \nuser-wide settings.json than hardcoded in our script. Remove the line to \nuse VS Code's default, or the user's setting.\n\n > (Add his own configuration).\n\nAvoid using gender-specific formulation when not needed. It's easier to \ndo in English than in French.\n\n > Add useful links in contrib/vscode/README.md to help the user to\n > configure his VS Code and how to use the debugging feature.\n\nLikewise.\n\n > Add a mention to the README in Documentation/MyFirstContribution.txt\n > and a part \"To convince a newcomer that VS Code can help him\".\n\nWhy use double-quotes here? You're not quoting anything, right?\n\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -1265,3 +1265,15 @@ against the appropriate GitGitGadget/Git branch.\n> If you're using `git send-email`, you can use it the same way as before, but you\n> should generate your diffs from `..` and base your work on\n> `` instead of `master`.\n> +\n> +[[Bonus-useful-tools]]\n> +== Bonus - useful tools\n> +\n> +=== VS Code\n> +\n> +To see \"how to use VS Code\" read contrib/vscode/README.md.\n\nDouble-quotes look weird here too. And the document is not really about \nusing VS Code, but more specifically on how to use VS Code on Git's \ncodebase.\n\nA set of scripts and instructions to use VS Code on Git's codebase is \navailable in `contrib/vscode/README.md`.\n\n?\n\n> +If you want to try to understand \"how git works internally\", the debugging\n> +feature of VS Code can help you. It will not give you all the keys to\n> fully understand it, but\n> +it can give you an idea of \"how the information travels inside the code\".\n> +It can help you to isolate some parts of code, with this you are able\n> +to ask more precise questions when you are stuck. (See getting-help sections).\n> \\ No newline at end of file\n\nI'm reluctant to adding general programming tips in a Git-specific \ndocument. Perhaps shorten it to eg. just \"Using the integrated debugger \ncan be particularly helpful to understand how Git works internally\"?\n\n> --- a/contrib/vscode/README.md\n> +++ b/contrib/vscode/README.md\n> @@ -8,6 +8,11 @@ code editor which runs on your desktop and is available for\n> [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n> it has [support for C/C++ via an\n> extension](https://github.com/Microsoft/vscode-cpptools).\n> +To understand \"how works the debugging part\" read:\n\n\"How the debugging part works\" to get words in the proper order.\n\nBut the flow would be more natural continuing the previous sentence IMHO:\n\n it has [support for C/C++ via an \nextension](https://github.com/Microsoft/vscode-cpptools) with [debugging \nsupport](https://code.visualstudio.com/docs/editor/debugging).\n\n> +To get help about \"how to personalize your settings\" read:\n> +[How to set up your\n> settings](https://code.visualstudio.com/docs/getstarted/settings)\n\nWhy not, but I don't think it's necessary here. People familiar with VS \nCode don't need such link, and people not familiar at all with is would \nbetter read a tutorial.\n\nCheers,\n\n-- \nMatthieu Moy\nhttps://matthieu-moy.fr/\n"},{"id":"453153","messageId":"20220405224502.38544-1-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"6f4b924d-0a13-b267-6766-a3620936b686@univ-lyon1.fr","subject":"[PATCH V1 0/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-05T22:45:01Z","receivedAt":"2022-04-06T05:07:47Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"> On 4/5/22 11:43, Matthieu Moy wrote:\n\n> How did you generate this patch? It doesn't apply with 'git am', I \n> suspect you copy-pasted incorrectly into your mailer. Using 'git \n> send-email' helps sending properly formatted patches.\n\nMy bad, I copy and paste. \nI'm a bit ashamed to say it, but I didn't know about the command 'git am',\nbut never too late to know about it, so thanks.\n\n> I usually explain the problem first, and then the solution.\n\nYes, if you don't mind, I take your explanation and put it inside the commit\nbecause it sounds really good to me. So, if I had to add a special tag for \nthis alert me.\n\n> A set of scripts and instructions to use VS Code on Git's codebase is\n> available in `contrib/vscode/README.md` ?.\n\nIndeed, it's a bit confused the way I said it. So, I change the text \nto something more accurate.\n\n> I'm reluctant to adding general programming tips in a Git-specific\n> document. Perhaps shorten it to eg. just \"Using the integrated debugger\n> can be particularly helpful to understand how Git works internally\"?\n\nI know, it can be strange to talk about programming tips, but I also think that,\nit can be a good idea if it could help a beginer. And I also think that, in \nMyFirstContribution it's the right place to talk about it, because it might be\nthe first reading of newcomers. But, maybe create another file to talk\nabout things like this with a mention of this file in MyFirstContribution \ncan be good too.\n\n> Why not, but I don't think it's necessary here. People familiar with VS\n> Code don't need such link, and people not familiar at all with is would\n> better read a tutorial.\n\nYou got a point, but like you said, why not.\n\n\nThanks for your help and for taking your time to review.\n\n\n\nCOGONI Guillaume (1):\n contrib/vscode/: debugging with VS Code and gdb\n\n Documentation/MyFirstContribution.txt | 11 +++++++++++\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 3 files changed, 16 insertions(+), 2 deletions(-)\n\n\nDifference between V0 and V1\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 97f53f536d..7f48990cb8 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1271,9 +1271,8 @@ should generate your diffs from `..` and base your work on\n \n === VS Code\n \n-To see \"how to use VS Code\" read contrib/vscode/README.md.\n-If you want to try to understand \"how git works internally\", the debugging\n-feature of VS Code can help you. It will not give you all the keys to fully understand it, but\n-it can give you an idea of \"how the informations travel inside the code\".\n-It can help you to isolate some parts of code, with this you are able\n-to ask more precises question when you are stuck. (See getting-help sections).\n+Using the integrate debugger can be particularly helpful to understand how Git works internally.\n+It can be used to isolate some parts of code, with this you may be able to ask more precises\n+question when you are stuck. (See getting-help sections).\n+A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n+and explanation of how to use the script are available in contrib/vscode/README.md.\n\ndiff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\nindex a416a752c1..f383c95e1f 100644\n--- a/contrib/vscode/README.md\n+++ b/contrib/vscode/README.md\n@@ -6,10 +6,9 @@ code editor which runs on your desktop and is available for\n [Windows](https://code.visualstudio.com/docs/setup/windows),\n [macOS](https://code.visualstudio.com/docs/setup/mac) and\n [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n-it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n+it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n+[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n \n-To understand \"how works the debbuging part\" read:\n-[Help with the debbuging part](https://code.visualstudio.com/docs/editor/debugging)\n To get help about \"how to personalize your settings\" read:\n [How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n\n\n-- \n2.25.1\n\n"},{"id":"453154","messageId":"20220405224502.38544-2-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"20220405224502.38544-1-cogoni.guillaume@gmail.com","subject":"[PATCH V1 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-05T22:45:02Z","receivedAt":"2022-04-06T05:07:47Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"The externalConsole=true setting is broken for many users (launching the\ndebugger with such setting results in VS Code waiting forever without\nactually starting the debugger). Also, this setting is a matter of user\npreference, and is arguably better set in a \"launch\" section in the\nuser-wide settings.json than hardcoded in our script. Remove the line to\nuse VS Code's default, or the user's setting.\n\nAdd useful links in contrib/vscode/README.md to help the user to\nconfigure VS Code and how to use the debugging feature.\n\nAdd a mention to the README and the init.sh in Documentation/MyFirstContribution.txt\nand a part to convince a newcomer that VS Code can help him.\n\nSigned-off-by: COGONI Guillaume \nCo-authored-by: BRESSAT Jonathan \nHelped-by: Matthieu Moy \nHelped-by: Derrick Stolee \n---\n Documentation/MyFirstContribution.txt | 11 +++++++++++\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 3 files changed, 16 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 63a2ef5449..7f48990cb8 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1265,3 +1265,14 @@ against the appropriate GitGitGadget/Git branch.\n If you're using `git send-email`, you can use it the same way as before, but you\n should generate your diffs from `..` and base your work on\n `` instead of `master`.\n+\n+[[Bonus-useful-tools]]\n+== Bonus - useful tools\n+\n+=== VS Code\n+\n+Using the integrate debugger can be particularly helpful to understand how Git works internally.\n+It can be used to isolate some parts of code, with this you may be able to ask more precises\n+question when you are stuck. (See getting-help sections).\n+A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n+and explanation of how to use the script are available in contrib/vscode/README.md.\ndiff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\nindex 8202d62035..f383c95e1f 100644\n--- a/contrib/vscode/README.md\n+++ b/contrib/vscode/README.md\n@@ -6,7 +6,11 @@ code editor which runs on your desktop and is available for\n [Windows](https://code.visualstudio.com/docs/setup/windows),\n [macOS](https://code.visualstudio.com/docs/setup/mac) and\n [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n-it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n+it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n+[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n+\n+To get help about \"how to personalize your settings\" read:\n+[How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n \n To start developing Git with VS Code, simply run the Unix shell script called\n `init.sh` in this directory, which creates the configuration files in\ndiff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\nindex 27de94994b..f139fd8644 100755\n--- a/contrib/vscode/init.sh\n+++ b/contrib/vscode/init.sh\n@@ -271,7 +271,6 @@ cat >.vscode/launch.json.new < +Using the integrate debugger can be particularly helpful to understand how Git works internally.\n> +It can be used to isolate some parts of code, with this you may be able to ask more precises\n> +question when you are stuck. (See getting-help sections).\n> +A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n> +and explanation of how to use the script are available in contrib/vscode/README.md.\n> diff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\n> index 8202d62035..f383c95e1f 100644\n> --- a/contrib/vscode/README.md\n> +++ b/contrib/vscode/README.md\n> @@ -6,7 +6,11 @@ code editor which runs on your desktop and is available for\n> [Windows](https://code.visualstudio.com/docs/setup/windows),\n> [macOS](https://code.visualstudio.com/docs/setup/mac) and\n> [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n> -it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n> +it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n> +[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n> +\n> +To get help about \"how to personalize your settings\" read:\n> +[How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n> \n\nThe upthread \"How did you generate this patch\" question from Matthieu\nstill seems to apply. I.e.:\n\n> To start developing Git with VS Code, simply run the Unix shell script called\n> `init.sh` in this directory, which creates the configuration files in\n\nThis context is something that's not there in the file on \"master\".\n\nI really don't mind having some guide for VSCode in our developer\ndocumentation, but I think if we (as a free software project) are\nrecommending proprietary software we should put that in some context\nwhere we explain if/why it's needed, and if free alternatives are also\nsuitable.\n\nI haven't used the VSCode integration you're documenting, but from the\ndiff and the \"gdb\" mention I gather that this isn't using some \"native\"\ndebugger of MSVC/VS's, but just using the VSCode editor as a wrapper for\ngdb?\n\nIf that's the case wouldn't it suffice to link to some generic getting\nstarted guide for debuggers? And e.g. recommend the GDB manual, maybe\nthere's a better online reference (I read it locally), but e.g.:\nhttps://www.sourceware.org/gdb/current/onlinedocs/gdb.html\n\nThen if we're recommending GUI wrappers those are a dime a dozen,\ne.g. Emacs's GUD mode:\nhttps://www.gnu.org/software/emacs/manual/html_node/emacs/Debuggers.html\n"},{"id":"453179","messageId":"27156ff7-4a8b-d428-0676-5eba002e3659@matthieu-moy.fr","threadId":"57610","inReplyTo":"20220405224502.38544-2-cogoni.guillaume@gmail.com","subject":"Re: [PATCH V1 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@matthieu-moy.fr","sentAt":"2022-04-06T11:59:13Z","receivedAt":"2022-04-06T15:39:40Z","isPatch":true,"sender":{"key":"matthieu.moy@matthieu-moy.fr","avatar":"https://gravatar.com/avatar/0d82caa87c23154bfb465283a9678b89180ce8b6e07e9da84f9ee111183c7fbc?d=mp&s=160"},"body":"On 4/6/22 00:45, COGONI Guillaume wrote:\n> The externalConsole=true setting is broken for many users (launching the\n> debugger with such setting results in VS Code waiting forever without\n> actually starting the debugger). Also, this setting is a matter of user\n> preference, and is arguably better set in a \"launch\" section in the\n> user-wide settings.json than hardcoded in our script. Remove the line to\n> use VS Code's default, or the user's setting.\n> \n> Add useful links in contrib/vscode/README.md to help the user to\n> configure VS Code and how to use the debugging feature.\n> \n> Add a mention to the README and the init.sh in Documentation/MyFirstContribution.txt\n> and a part to convince a newcomer that VS Code can help him.\n\nYou may avoid the gender-specific formulation here, women should be as \ninterested as men in the document.\n\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -1265,3 +1265,14 @@ against the appropriate GitGitGadget/Git branch.\n> If you're using `git send-email`, you can use it the same way as before, but you\n> should generate your diffs from `..` and base your work on\n> `` instead of `master`.\n> +\n> +[[Bonus-useful-tools]]\n> +== Bonus - useful tools\n> +\n> +=== VS Code\n> +\n> +Using the integrate debugger can be particularly helpful to understand how Git works internally.\n> +It can be used to isolate some parts of code, with this you may be able to ask more precises\n> +question when you are stuck. (See getting-help sections).\n> +A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n> +and explanation of how to use the script are available in contrib/vscode/README.md.\n\nI'd start with the last sentence. People already familiar with VS Code \nmay find the first line boring, and stop reading before reaching the \nimportant information.\n\nWith or without changes, this is\n\nAcked-by: Matthieu Moy \n\n--\nMatthieu Moy\nhttps://matthieu-moy.fr/\n"},{"id":"453180","messageId":"84f77a5b-5721-3583-8ed8-9d360928cf35@matthieu-moy.fr","threadId":"57610","inReplyTo":"20220405224502.38544-2-cogoni.guillaume@gmail.com","subject":"Re: [PATCH V1 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"Matthieu Moy","fromEmail":"git@matthieu-moy.fr","sentAt":"2022-04-06T13:35:51Z","receivedAt":"2022-04-06T16:31:01Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"On 4/6/22 00:45, COGONI Guillaume wrote:\n> The externalConsole=true setting is broken for many users (launching the\n> debugger with such setting results in VS Code waiting forever without\n> actually starting the debugger). Also, this setting is a matter of user\n> preference, and is arguably better set in a \"launch\" section in the\n> user-wide settings.json than hardcoded in our script. Remove the line to\n> use VS Code's default, or the user's setting.\n> \n> Add useful links in contrib/vscode/README.md to help the user to\n> configure VS Code and how to use the debugging feature.\n> \n> Add a mention to the README and the init.sh in Documentation/MyFirstContribution.txt\n> and a part to convince a newcomer that VS Code can help him.\n\nYou may avoid the gender-specific formulation here, women should be as \ninterested as men in the document.\n\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -1265,3 +1265,14 @@ against the appropriate GitGitGadget/Git branch.\n> If you're using `git send-email`, you can use it the same way as before, but you\n> should generate your diffs from `..` and base your work on\n> `` instead of `master`.\n> +\n> +[[Bonus-useful-tools]]\n> +== Bonus - useful tools\n> +\n> +=== VS Code\n> +\n> +Using the integrate debugger can be particularly helpful to understand how Git works internally.\n> +It can be used to isolate some parts of code, with this you may be able to ask more precises\n> +question when you are stuck. (See getting-help sections).\n> +A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n> +and explanation of how to use the script are available in contrib/vscode/README.md.\n\nI'd start with the last sentence. People already familiar with VS Code \nmay find the first line boring, and stop reading before reaching the \nimportant information.\n\nWith or without changes, this is\n\nAcked-by: Matthieu Moy \n\n--\nMatthieu Moy\nhttps://matthieu-moy.fr/\n"},{"id":"453188","messageId":"20220406151858.5047-1-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"84f77a5b-5721-3583-8ed8-9d360928cf35@matthieu-moy.fr","subject":"[PATCH v2 0/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-06T15:18:57Z","receivedAt":"2022-04-06T17:19:19Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"> On 6/5/22 10:54 AM, Matthieu Moy wrote:\n\n> but I think if we (as a free software project) are\n> recommending proprietary software we should put that in some context\n> where we explain if/why it's needed, and if free alternatives are also\n> suitable.\n\n> If that's the case wouldn't it suffice to link to some generic getting\n> started guide for debuggers? \n\nYou got a point, it's a bit paradoxical, but I don't know any good alternatives\nand I don't want to advise someone with something that I don't be familiar with.\nBut, in the future, if someone wants to add alternatives it will be good.\n\n> I haven't used the VSCode integration you're documenting, but from the\n> diff and the \"gdb\" mention I gather that this isn't using some \"native\"\n> debugger of MSVC/VS's, but just using the VSCode editor as a wrapper for\n> gdb?\n\nIt can be use as a wrapper for the following debugger:\n Linux: GDB\n macOS: LLDB or GDB\n Windows: the Visual Studio Windows Debugger or GDB (using Cygwin or MinGW)\nSource : https://code.visualstudio.com/docs/cpp/cpp-debug#_gdb-lldb-and-lldbmi-commands-gdblldb\n\n\nThanks for your reviewing.\n\n\n> On 6/5/22 1:59 PM, Matthieu Moy wrote:\n\n> I'd start with the last sentence. People already familiar with VS Code\n> may find the first line boring, and stop reading before reaching the\n> important information.\n\nYeah, sure, I don't think about the expert that must just want to know\nabout the script.\n\n> Acked-by: Matthieu Moy \n\nThanks.\n\n\nCOGONI Guillaume (1):\n contrib/vscode/: debugging with VS Code and gdb\n\n Documentation/MyFirstContribution.txt | 11 +++++++++++\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 3 files changed, 16 insertions(+), 2 deletions(-)\n\nDiff-intervalle between v1 and v2 :\n1: 2a7d50ca5c ! 1: 367a478855 contrib/vscode/: debugging with VS Code and gdb\n @@ Commit message\n \n Add a mention to the README and the init.sh in Documentation/\n MyFirstContribution.txt and a part to convince a newcomer that VS Code\n- can help him.\n+ can be helpful.\n \n Signed-off-by: COGONI Guillaume \n Co-authored-by: BRESSAT Jonathan \n\n @@ Documentation/MyFirstContribution.txt: against the appropriate GitGitGadget/Git\n+\n+=== VS Code\n+\n++A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n++and explanation of how to use the script are available in contrib/vscode/README.md.\n+Using the integrate debugger can be particularly helpful to understand how Git works internally.\n+It can be used to isolate some parts of code, with this you may be able to ask more precises\n+question when you are stuck. (See getting-help sections).\n-+A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n-+and explanation of how to use the script are available in contrib/vscode/README.md.\n\\ No newline at end of file\n \n ## contrib/vscode/README.md ##\n-- \n2.25.1\n\n"},{"id":"453189","messageId":"20220406151858.5047-2-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"20220406151858.5047-1-cogoni.guillaume@gmail.com","subject":"[PATCH v2 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-06T15:18:58Z","receivedAt":"2022-04-06T17:19:22Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"The externalConsole=true setting is broken for many users (launching the\ndebugger with such setting results in VS Code waiting forever without\nactually starting the debugger). Also, this setting is a matter of user\npreference, and is arguably better set in a \"launch\" section in the\nuser-wide settings.json than hardcoded in our script. Remove the line to\nuse VS Code's default, or the user's setting.\n\nAdd useful links in contrib/vscode/README.md to help the user to\nconfigure VS Code and how to use the debugging feature.\n\nAdd a mention to the README and the init.sh in Documentation/\nMyFirstContribution.txt and a part to convince a newcomer that VS Code\ncan be helpful.\n\nSigned-off-by: COGONI Guillaume \nCo-authored-by: BRESSAT Jonathan \nHelped-by: Matthieu Moy \nHelped-by: Derrick Stolee \n---\n Documentation/MyFirstContribution.txt | 11 +++++++++++\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 3 files changed, 16 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 63a2ef5449..9cdb661271 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1265,3 +1265,14 @@ against the appropriate GitGitGadget/Git branch.\n If you're using `git send-email`, you can use it the same way as before, but you\n should generate your diffs from `..` and base your work on\n `` instead of `master`.\n+\n+[[Bonus-useful-tools]]\n+== Bonus - useful tools\n+\n+=== VS Code\n+\n+A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n+and explanation of how to use the script are available in contrib/vscode/README.md.\n+Using the integrate debugger can be particularly helpful to understand how Git works internally.\n+It can be used to isolate some parts of code, with this you may be able to ask more precises\n+question when you are stuck. (See getting-help sections).\n\\ No newline at end of file\ndiff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\nindex 8202d62035..f383c95e1f 100644\n--- a/contrib/vscode/README.md\n+++ b/contrib/vscode/README.md\n@@ -6,7 +6,11 @@ code editor which runs on your desktop and is available for\n [Windows](https://code.visualstudio.com/docs/setup/windows),\n [macOS](https://code.visualstudio.com/docs/setup/mac) and\n [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n-it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n+it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n+[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n+\n+To get help about \"how to personalize your settings\" read:\n+[How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n \n To start developing Git with VS Code, simply run the Unix shell script called\n `init.sh` in this directory, which creates the configuration files in\ndiff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\nindex 27de94994b..f139fd8644 100755\n--- a/contrib/vscode/init.sh\n+++ b/contrib/vscode/init.sh\n@@ -271,7 +271,6 @@ cat >.vscode/launch.json.new < The externalConsole=true setting is broken for many users (launching the\n> debugger with such setting results in VS Code waiting forever without\n> actually starting the debugger). Also, this setting is a matter of user\n> preference, and is arguably better set in a \"launch\" section in the\n> user-wide settings.json than hardcoded in our script. Remove the line to\n> use VS Code's default, or the user's setting.\n> \n> Add useful links in contrib/vscode/README.md to help the user to\n> configure VS Code and how to use the debugging feature.\n> \n> Add a mention to the README and the init.sh in Documentation/\n> MyFirstContribution.txt and a part to convince a newcomer that VS Code\n> can be helpful.\n\nSorry for not getting to this in v1.\n \n> Signed-off-by: COGONI Guillaume \n> Co-authored-by: BRESSAT Jonathan \n> Helped-by: Matthieu Moy \n> Helped-by: Derrick Stolee \n\nHere, you probably want to flip the order here (Helped-by, then\nCo-authored-by, then Signed-off-by). You probably also want the\nsign-off of your co-author, too.\n\nThe sign-off should be the last thing in the message, because\nthe previous lines are covered by that sign-off.\n\n> +\n> +[[Bonus-useful-tools]]\n> +== Bonus - useful tools\n> +\n> +=== VS Code\n\nHere, maybe use the full name, then the short version.\n\n === Visual Studio Code (VS Code)\n\n> +A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n> +and explanation of how to use the script are available in contrib/vscode/README.md.\n\nThis passive voice could be made active such as:\n\n The contrib/vscode/init.sh script creates configuration files that\n enable several valuable VS Code features. See contrib/vscode/README.md\n for more information on using the script.\n\nMake a new paragraph before talking about debuggers.\n\n> +Using the integrate debugger can be particularly helpful to understand how Git works internally.\n> +It can be used to isolate some parts of code, with this you may be able to ask more precises\n> +question when you are stuck. (See getting-help sections).\n\nI would focus less on \"benefits of debugging\" and focus instead on\n\"benefits of debugging using your GUI editor\". Something like this\nmight be a good start:\n\n In particular, this script enables using the VS Code visual debugger,\n including setting breakpoints in the editor.\n\n> \\ No newline at end of file\n\nFix this missing newline.\n\n> diff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\n> index 8202d62035..f383c95e1f 100644\n> --- a/contrib/vscode/README.md\n> +++ b/contrib/vscode/README.md\n> @@ -6,7 +6,11 @@ code editor which runs on your desktop and is available for\n> [Windows](https://code.visualstudio.com/docs/setup/windows),\n> [macOS](https://code.visualstudio.com/docs/setup/mac) and\n> [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n> -it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n> +it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n> +[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n> +\n> +To get help about \"how to personalize your settings\" read:\n> +[How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n\nThese changes are pretty standard, and I have no concerns here.\n\n> \"stopAtEntry\": false,\n> \"cwd\": \"\\${workspaceFolder}\",\n> \"environment\": [],\n> - \"externalConsole\": true,\n\nAnd this is the necessary fix.\n\nThanks for working on this!\n\nThanks,\n-Stolee\n\n"},{"id":"453226","messageId":"xmqqbkxex8oy.fsf@gitster.g","threadId":"57610","inReplyTo":"378c5790-f587-4e26-87be-8f856974e5ca@github.com","subject":"Re: [PATCH v2 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-06T20:23:25Z","receivedAt":"2022-04-06T21:25:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee writes:\n\n> \n>> Signed-off-by: COGONI Guillaume \n>> Co-authored-by: BRESSAT Jonathan \n>> Helped-by: Matthieu Moy \n>> Helped-by: Derrick Stolee \n>\n> Here, you probably want to flip the order here (Helped-by, then\n> Co-authored-by, then Signed-off-by). You probably also want the\n> sign-off of your co-author, too.\n>\n> The sign-off should be the last thing in the message, because\n> the previous lines are covered by that sign-off.\n\nYup. It would record the order of events that lead to this exact\npatch, which is what we want to capture. With help by these people,\ntogether with the co-author(s), the patch was written and author(s)\nsigned-off before it was sent out to the list.\n\n> ...\n> And this is the necessary fix.\n>\n> Thanks for working on this!\n\nIndeed. And thanks for a helpful review.\n"},{"id":"453237","messageId":"20220406233946.45778-1-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"xmqqbkxex8oy.fsf@gitster.g","subject":"[PATCH v3 0/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-06T23:39:45Z","receivedAt":"2022-04-06T23:40:09Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"On 4/6/2022 18:03 PM, Derrick Stolee wrote:\n\n> Sorry for not getting to this in v1.\n\nNo problem, I take this opportunity to get a better view of the review \nprocess.\n\n> Thanks for working on this!\n\nThanks for your help and reviewing.\n\n\nCOGONI Guillaume (1):\n contrib/vscode/: debugging with VS Code and gdb\n\n Documentation/MyFirstContribution.txt | 20 ++++++++++++++++++++\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 3 files changed, 25 insertions(+), 2 deletions(-)\n\nDiff-intervalle between v2 and v3 :\n1: 367a478855 ! 1: 0600ab64f8 contrib/vscode/: debugging with VS Code and gdb\n@@ Commit message\n MyFirstContribution.txt and a part to convince a newcomer that VS Code\n can be helpful.\n \n- Signed-off-by: COGONI Guillaume \n- Co-authored-by: BRESSAT Jonathan \n Helped-by: Matthieu Moy \n Helped-by: Derrick Stolee \n+ Co-authored-by: BRESSAT Jonathan \n+ Signed-off-by: COGONI Guillaume \n \n ## Documentation/MyFirstContribution.txt ##\n @@ Documentation/MyFirstContribution.txt: against the appropriate GitGitGadget/Git branch.\n@@ Documentation/MyFirstContribution.txt: against the appropriate GitGitGadget/Git\n+[[Bonus-useful-tools]]\n+== Bonus - useful tools\n+\n-+=== VS Code\n+=== Visual Studio Code (VS Code)\n+\n+The contrib/vscode/init.sh script creates configuration files that enable\n+several valuable VS Code features. See contrib/vscode/README.md for more\n+information on using the script.\n+\n+In particular, this script enables using the VS Code visual debugger, including\n+setting breakpoints, logpoints, conditional breakpoints in the editor.\n+In addition, it includes the ability to see the call stack, the line of code that\n+is executing and more. It is possible to visualize the variables and their values\n+and change them during execution.\n+\n-A script that creates the configuration files is available in contrib/vscode/init.sh. Useful links\n-and explanation of how to use the script are available in contrib/vscode/README.md.\n-Using the integrate debugger can be particularly helpful to understand how Git works internally.\n-It can be used to isolate some parts of code, with this you may be able to ask more precises\n-question when you are stuck. (See getting-help sections).\n- \\ No newline at end of file\n+In sum, using the built-in debugger can be particularly helpful to understand\n+how Git works internally.\n+It can be used to isolate certain parts of code, with this you may be able to ask\n+more precises question when you are stuck. (See getting-help sections).\n \n ## contrib/vscode/README.md ##\n @@ contrib/vscode/README.md: code editor which runs on your desktop and is available for\n-- \n2.25.1\n\n"},{"id":"453238","messageId":"20220406233946.45778-2-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"20220406233946.45778-1-cogoni.guillaume@gmail.com","subject":"[PATCH v3 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-06T23:39:46Z","receivedAt":"2022-04-06T23:40:11Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"The externalConsole=true setting is broken for many users (launching the\ndebugger with such setting results in VS Code waiting forever without\nactually starting the debugger). Also, this setting is a matter of user\npreference, and is arguably better set in a \"launch\" section in the\nuser-wide settings.json than hardcoded in our script. Remove the line to\nuse VS Code's default, or the user's setting.\n\nAdd useful links in contrib/vscode/README.md to help the user to\nconfigure VS Code and how to use the debugging feature.\n\nAdd a mention to the README and the init.sh in Documentation/\nMyFirstContribution.txt and a part to convince a newcomer that VS Code\ncan be helpful.\n\nHelped-by: Matthieu Moy \nHelped-by: Derrick Stolee \nCo-authored-by: BRESSAT Jonathan \nSigned-off-by: COGONI Guillaume \n---\n Documentation/MyFirstContribution.txt | 20 ++++++++++++++++++++\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 3 files changed, 25 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex 63a2ef5449..fc53456527 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1265,3 +1265,23 @@ against the appropriate GitGitGadget/Git branch.\n If you're using `git send-email`, you can use it the same way as before, but you\n should generate your diffs from `..` and base your work on\n `` instead of `master`.\n+\n+[[Bonus-useful-tools]]\n+== Bonus - useful tools\n+\n+=== Visual Studio Code (VS Code)\n+\n+The contrib/vscode/init.sh script creates configuration files that enable\n+several valuable VS Code features. See contrib/vscode/README.md for more\n+information on using the script.\n+\n+In particular, this script enables using the VS Code visual debugger, including\n+setting breakpoints, logpoints, conditional breakpoints in the editor.\n+In addition, it includes the ability to see the call stack, the line of code that\n+is executing and more. It is possible to visualize the variables and their values\n+and change them during execution.\n+\n+In sum, using the built-in debugger can be particularly helpful to understand\n+how Git works internally.\n+It can be used to isolate certain parts of code, with this you may be able to ask\n+more precises question when you are stuck. (See getting-help sections).\ndiff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\nindex 8202d62035..f383c95e1f 100644\n--- a/contrib/vscode/README.md\n+++ b/contrib/vscode/README.md\n@@ -6,7 +6,11 @@ code editor which runs on your desktop and is available for\n [Windows](https://code.visualstudio.com/docs/setup/windows),\n [macOS](https://code.visualstudio.com/docs/setup/mac) and\n [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n-it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n+it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n+[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n+\n+To get help about \"how to personalize your settings\" read:\n+[How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n \n To start developing Git with VS Code, simply run the Unix shell script called\n `init.sh` in this directory, which creates the configuration files in\ndiff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\nindex 27de94994b..f139fd8644 100755\n--- a/contrib/vscode/init.sh\n+++ b/contrib/vscode/init.sh\n@@ -271,7 +271,6 @@ cat >.vscode/launch.json.new < \n> On Wed, Apr 06 2022, COGONI Guillaume wrote:\n> \n> I really don't mind having some guide for VSCode in our developer\n> documentation, but I think if we (as a free software project) are\n> recommending proprietary software we should put that in some context\n> where we explain if/why it's needed, and if free alternatives are also\n> suitable.\n\nNote that VS Code is mostly open source (the pre-compiled binaries are \nproprietary, but the source code is MIT licenced, \nhttps://github.com/Microsoft/vscode). Not to be confused with Visual \nStudio, which is fully proprietary, but is a totally different tool \n(AFAIK, they only share the name).\n\n> I haven't used the VSCode integration you're documenting, but from the\n> diff and the \"gdb\" mention I gather that this isn't using some \"native\"\n> debugger of MSVC/VS's, but just using the VSCode editor as a wrapper for\n> gdb?\n\nYes (gdb or lldb under the hood). As usual, it adds a GUI layer, but \nalso a configuration layer where you specify how to launch the debugger \nin a launch.json file, and this is where the little script in contrib/ \nis handy to generate a launch.json adapted for Git.\n\n> If that's the case wouldn't it suffice to link to some generic getting\n> started guide for debuggers? And e.g. recommend the GDB manual, maybe\n> there's a better online reference (I read it locally), but e.g.:\n> https://www.sourceware.org/gdb/current/onlinedocs/gdb.html\n\nTo me the point of the doc within Git's repo is to document git-specific \naspects, and I agree that pointing to a generic doc is better than \nre-writing one. If I had written the patch I'd have made the general \nparagraph on debugger benefits a bit shorter, but it's already rather \nshort so I'm OK with the patch in its current state.\n\n> Then if we're recommending GUI wrappers those are a dime a dozen,\n> e.g. Emacs's GUD mode:\n> https://www.gnu.org/software/emacs/manual/html_node/emacs/Debuggers.html\n\nTo me this is out of the scope of the patch (the real point to me was to \nincrease the discoverability of contrib/vscode), but sure, documenting \nother GUI wrappers would be nice.\n\n-- \nMatthieu Moy\nhttps://matthieu-moy.fr/\n"},{"id":"453250","messageId":"220407.86tub5ce3m.gmgdl@evledraar.gmail.com","threadId":"57610","inReplyTo":"20220406233946.45778-2-cogoni.guillaume@gmail.com","subject":"Re: [PATCH v3 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-04-07T11:17:20Z","receivedAt":"2022-04-07T11:44:39Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\n[Partially in reply to Matthieu Moy's\nhttps://lore.kernel.org/git/6a5152c1-7bb4-220c-cdce-33e93ea9c7c6@univ-lyon1.fr/,\nbut it seems more useful to continue here in the v3 thread]\n\nOn Thu, Apr 07 2022, COGONI Guillaume wrote:\n\n> Add a mention to the README and the init.sh in Documentation/\n> MyFirstContribution.txt and a part to convince a newcomer that VS Code\n> can be helpful.\n\nAside from this specific addition of a section about VSCode it says at\nthe top of of Documentation/MyFirstContribution.txt:\n\t\n\tThis tutorial aims to summarize the following documents, but the reader may find\n\tuseful additional context:\n\t\n\t- `Documentation/SubmittingPatches`\n\t- `Documentation/howto/new-command.txt`\n\nShould we have anything in MyFirstContribution.txt that isn't already\ncovered there per that statement at the top?\n\n[Combining replies at this point]\n\nOn Thu, Apr 07 2022, Matthieu Moy wrote:\n\n> On 4/6/22 10:47, Ævar Arnfjörð Bjarmason wrote:\n>> On Wed, Apr 06 2022, COGONI Guillaume wrote:\n>> I really don't mind having some guide for VSCode in our developer\n>> documentation, but I think if we (as a free software project) are\n>> recommending proprietary software we should put that in some context\n>> where we explain if/why it's needed, and if free alternatives are also\n>> suitable.\n>\n> Note that VS Code is mostly open source (the pre-compiled binaries are\n> proprietary, but the source code is MIT licenced, \n> https://github.com/Microsoft/vscode). Not to be confused with Visual\n> Studio, which is fully proprietary, but is a totally different tool \n> (AFAIK, they only share the name).\n\nThis patch specifically proposed to link to the propriterary version.\n\nIs there a reason we wouldn't at least recommend the fully-free version\nat https://github.com/VSCodium/vscodium, or at least mention it as\nprominently?\n\n>> I haven't used the VSCode integration you're documenting, but from the\n>> diff and the \"gdb\" mention I gather that this isn't using some \"native\"\n>> debugger of MSVC/VS's, but just using the VSCode editor as a wrapper for\n>> gdb?\n>\n> Yes (gdb or lldb under the hood). As usual, it adds a GUI layer, but\n> also a configuration layer where you specify how to launch the\n> debugger in a launch.json file, and this is where the little script in\n> contrib/ is handy to generate a launch.json adapted for Git.\n>\n>> If that's the case wouldn't it suffice to link to some generic getting\n>> started guide for debuggers? And e.g. recommend the GDB manual, maybe\n>> there's a better online reference (I read it locally), but e.g.:\n>> https://www.sourceware.org/gdb/current/onlinedocs/gdb.html\n>\n> To me the point of the doc within Git's repo is to document\n> git-specific aspects, and I agree that pointing to a generic doc is\n> better than re-writing one. If I had written the patch I'd have made\n> the general paragraph on debugger benefits a bit shorter, but it's\n> already rather short so I'm OK with the patch in its current state.\n>\n>> Then if we're recommending GUI wrappers those are a dime a dozen,\n>> e.g. Emacs's GUD mode:\n>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Debuggers.html\n>\n> To me this is out of the scope of the patch (the real point to me was\n> to increase the discoverability of contrib/vscode), but sure,\n> documenting other GUI wrappers would be nice.\n> [...]\n> +\n> +[[Bonus-useful-tools]]\n> +== Bonus - useful tools\n> +\n> +=== Visual Studio Code (VS Code)\n> +\n> +The contrib/vscode/init.sh script creates configuration files that enable\n> +several valuable VS Code features. See contrib/vscode/README.md for more\n> +information on using the script.\n> +\n> +In particular, this script enables using the VS Code visual debugger, including\n> +setting breakpoints, logpoints, conditional breakpoints in the editor.\n> +In addition, it includes the ability to see the call stack, the line of code that\n> +is executing and more. It is possible to visualize the variables and their values\n> +and change them during execution.\n> +\n> +In sum, using the built-in debugger can be particularly helpful to understand\n> +how Git works internally.\n> +It can be used to isolate certain parts of code, with this you may be able to ask\n> +more precises question when you are stuck. (See getting-help sections).\n> diff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\n> index 8202d62035..f383c95e1f 100644\n> --- a/contrib/vscode/README.md\n> +++ b/contrib/vscode/README.md\n> @@ -6,7 +6,11 @@ code editor which runs on your desktop and is available for\n> [Windows](https://code.visualstudio.com/docs/setup/windows),\n> [macOS](https://code.visualstudio.com/docs/setup/mac) and\n> [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n> -it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n> +it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n> +[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n> +\n> +To get help about \"how to personalize your settings\" read:\n> +[How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n\nTwo things:\n\nFirst I think (disclaimer: being on the Git PLC this is just my opinion)\nthat as a prominent free software project, and being under the Software\nFreedom Conservancy umbrella whose mission is\n(https://sfconservancy.org/):\n\n [...] fostering free and open source software (FOSS) projects,\n driving initiatives that actively make technology more inclusive,\n and advancing policy strategies that defend FOSS (such as copyleft).\n\nSo, maybe I'm just an old free software radical, but I believe in\ninterpreting that broadly. I.e. if we're recommending third-party\nsoftware we should prefer free alternatives, which doesn't mean that we\ncan't mention proprietary software, just that we shouldn't be\nencouraging it when a free alternative will do.\n\nBut secondly, and everything here would apply if VSCode were replaced by\nGNU Emacs and its GUD mode, so it's not about free software on VSCode at\nall: This whole addition just seems like it's recommending a needlessly\ncomplex way to get to having a C debugger installed.\n\nLeaving aside completely *where* we should put such a thing I'd expect\nsomething much more like:\n\t\n\tBEGIN QUOTE\n\t\n\t== Using debuggers ==\n\t\n\tYou'll probably find it useful to use a debugger to\n\tinteractively inspect your code as it's running.\n\t\n\tThere's numerous such debuggers, and you may even have one installed\n\talready along with your development toolchain.\n\t\n\tThe GNU debugger (gdb) is probably the most common one command-line\n\tdebugger, along with the LLDB debugger (lldb):\n\t\n\t\thttps://www.sourceware.org/gdb/\n\t\thttps://lldb.llvm.org/\n\t\n\t=== GUIs ===\n\t\n\tSome users find using such a debugger to be rather \"bare bones\" on the\n\tcommand-line, but there's numerous GUIs or \"front-ends\" for them\n\tavailable. You may even find that your editort (e.g. GNU emacs) ships\n\twith such a frontend already. You may find a listing of some at (some of\n\tthese work with lldb as well as gdb):\n\t\n\t http://sourceware.org/gdb/wiki/GDB%20Front%20Ends\n\t\n\tWe also have helper code in-tree to launch debuggers from some\n\teditors. If you use on of these editors you may find that handy:\n\t\n\t\tVSCode: contrib/vscode/README.md\n\t\n\t=== Debugging test failures ===\n\t\n\tIf you'd like to start an interactive debugger at the ponit where a test\n\tfails you may find the \"debug\" wrapper in t/test-lib-functions.sh useful\n\tfor that.\n\t\n\tEND QUOTE\n\nI.e. it really shouldn't be the goal of a section on debuggers to\n\"convince a newcomer that VS Code can be helpful\", or that Emacs is\nhelpful or whatever. Let's instead discuss the general topic at hand.\n\nThe proposed addition buries the lede in that regard. I.e. it's not made\nclear to the reader that we're just suggesting yet another interface for\ngdb, so a beginning contributor might go through it, only to find that\nall they needed was gdb, and they had that installed already.\n"},{"id":"453256","messageId":"ea70aed6-7111-0795-f6d8-15deb505b1c0@github.com","threadId":"57610","inReplyTo":"220407.86tub5ce3m.gmgdl@evledraar.gmail.com","subject":"Re: [PATCH v3 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"Derrick Stolee","fromEmail":"derrickstolee@github.com","sentAt":"2022-04-07T13:09:23Z","receivedAt":"2022-04-07T13:09:32Z","isPatch":true,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 4/7/2022 7:17 AM, Ævar Arnfjörð Bjarmason wrote:\n>> On 4/6/22 10:47, Ævar Arnfjörð Bjarmason wrote:\n>>> On Wed, Apr 06 2022, COGONI Guillaume wrote:\n>>> I really don't mind having some guide for VSCode in our developer\n>>> documentation, but I think if we (as a free software project) are\n>>> recommending proprietary software we should put that in some context\n>>> where we explain if/why it's needed, and if free alternatives are also\n>>> suitable.\n>>\n>> Note that VS Code is mostly open source (the pre-compiled binaries are\n>> proprietary, but the source code is MIT licenced, \n>> https://github.com/Microsoft/vscode). Not to be confused with Visual\n>> Studio, which is fully proprietary, but is a totally different tool \n>> (AFAIK, they only share the name).\n> \n> This patch specifically proposed to link to the propriterary version.\n> \n> Is there a reason we wouldn't at least recommend the fully-free version\n> at https://github.com/VSCodium/vscodium, or at least mention it as\n> prominently?\n\nI think it is find to add such a reference, but I doubt it will have\nmuch value to the reader. If the strangeness around how VS Code is\ncompiled bothers the reader, then they probably already avoid it.\n\nI think this is an excellent thing to consider as a follow-up by an\nexpert on the topic, such as yourself, and not prevent this patch from\nmoving forward from the current authors.\n\n> Two things:\n> \n> First I think (disclaimer: being on the Git PLC this is just my opinion)\n> that as a prominent free software project, and being under the Software\n> Freedom Conservancy umbrella whose mission is\n> (https://sfconservancy.org/):\n> \n> [...] fostering free and open source software (FOSS) projects,\n> driving initiatives that actively make technology more inclusive,\n> and advancing policy strategies that defend FOSS (such as copyleft).\n> \n> So, maybe I'm just an old free software radical, but I believe in\n> interpreting that broadly. I.e. if we're recommending third-party\n> software we should prefer free alternatives, which doesn't mean that we\n> can't mention proprietary software, just that we shouldn't be\n> encouraging it when a free alternative will do.\n\nSometimes, we need to meet people where they are. If they choose to\nuse a proprietary editor, we can help them use that to work on our\nproject.\n\n> But secondly, and everything here would apply if VSCode were replaced by\n> GNU Emacs and its GUD mode, so it's not about free software on VSCode at\n> all: This whole addition just seems like it's recommending a needlessly\n> complex way to get to having a C debugger installed.\n\nI completely agree with you that this should be the _start_ of the\nprocess of documenting how to debug with a bunch of editors. There are\nbenefits of connecting your editor to the debugger instead of relying\non gdb or whatever directly.\n\nI also find it hard to interpret the current section as \"Do you want to\ndebug Git? You should use VS Code!\" I _can_ see that the section on\n\"useful tools\" only contains one entry (so far) and that can be\nread as a recommendation. This should motivate those who use other tools\nto chime in with how they use their tools and what steps are required to\nget efficient integrations when working on Git.\n\n> Leaving aside completely *where* we should put such a thing I'd expect\n> something much more like:\n> \t\n> \tBEGIN QUOTE\n> \t\n> \t== Using debuggers ==\n...\n> \t=== GUIs ===\n...\n\nI was trying to make a similar recommendation in my review. The point is\nnot \"You should use a debugger, here is VS Code\", but rather \"If you want\nto use a debugger with your editor, here are ways to configure your\neditor of choice to debug Git.\" It is perfectly fine by me if these\nauthors want to start with the editor they know and use, as long as the\nstructure is such that it can be extended by other contributors to\ninclude these other editor.\n\n> \t=== Debugging test failures ===\n> \t\n> \tIf you'd like to start an interactive debugger at the ponit where a test\n> \tfails you may find the \"debug\" wrapper in t/test-lib-functions.sh useful\n> \tfor that.\n\nThis is a helpful idea to include in this section, but it is far too\nterse to be helpful to someone who doesn't know exactly what you mean\nby a '\"debug\" wrapper'. An example would go far here. This also\nrequires working with the command-line debugger (gdb, lldb, etc.), so\nshould be carefully differentiated from the GUI section. One way to\nestablish that difference would be to move it above the GUI section.\n\n> I.e. it really shouldn't be the goal of a section on debuggers to\n> \"convince a newcomer that VS Code can be helpful\", or that Emacs is\n> helpful or whatever. Let's instead discuss the general topic at hand.\n> \n> The proposed addition buries the lede in that regard. I.e. it's not made\n> clear to the reader that we're just suggesting yet another interface for\n> gdb, so a beginning contributor might go through it, only to find that\n> all they needed was gdb, and they had that installed already.\n\nI think that having a section on using debuggers in general, followed\nby specific ways to interact with a variety of editors, would be helpful.\n\nBut I also think that this contribution does not need to be burdened by\nthat increase in scope. The heading \"Bonus - useful tools\" is a good\nstart that can be extended in several ways by future contributions. One\nway is to reframe it as \"how to debug Git\" while another might be to\nadd other useful tools like clang-format or valgrind. I believe the best\nway to go here is to be happy with the contribution with its current\nscope and leave these later discussions for contributors with the right\nexpertise and time to write more documentation.\n\n----\n\nPerhaps this entire discussion would be different if the change was\nadded somewhere other than MyFirstContribution.txt. Is there a better\nfile to place this change?\n\nMyFirstContribution.txt provides a good start to the basics of\nmaking change, with a specific example giving chronological steps\nfor submitting a change. It seems like adding a section at the end\nof \"bonus tools\" does not fit that narrative.\n\nTaking a look myself, the only other places that _might_ make sense\ninclude CodingGuidelines (has some integrations with Emacs included)\nor SubmittingPatches (talks a lot about different email clients and\ntools that help).\n\nI think that we might want a new file where Git developers can\nshare best practices and custom workflows. Such a document could\nhelp contributors optimize their process to their own tastes based\non the experience of others. I can see a long list of integrations\nwith editors fitting in there, along with tips like \"create a RAM\ndisk for running tests\".\n\nMy proposed name for such a file is \"WorkingOnGit\" but it's not\nfantastic. Suggestions welcome.\n\n---\n\nCogoni: In conclusion, I think that if you remove the change to\nMyFirstContribution.txt, then your patch can be merged pretty\nquickly (probably, that's not my decision). I expect this discussion\nabout a potential \"WorkingOnGit\" file to continue, but if it comes\nto fruition, your section on VS Code would be welcome.\n\nThanks,\n-Stolee\n"},{"id":"453275","messageId":"xmqqmtgwu9n7.fsf@gitster.g","threadId":"57610","inReplyTo":"ea70aed6-7111-0795-f6d8-15deb505b1c0@github.com","subject":"Re: [PATCH v3 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-04-07T16:43:24Z","receivedAt":"2022-04-07T16:43:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Derrick Stolee writes:\n\n> Sometimes, we need to meet people where they are. If they choose to\n> use a proprietary editor, we can help them use that to work on our\n> project.\n\nYes, that's a good point to make. I found that the thrust of the\nsuggestion made in the last part of Ævar's message was \"if you are\nuser of VSCode, what we have in contrib/ may help your use of\ndebuggers in it\", which was in line with the above.\n\n>> Leaving aside completely *where* we should put such a thing I'd expect\n>> something much more like:\n>> \t\n>> \tBEGIN QUOTE\n>> \t\n>> \t== Using debuggers ==\n> ...\n>> \t=== GUIs ===\n> ...\n>\n> I was trying to make a similar recommendation in my review. The point is\n> not \"You should use a debugger, here is VS Code\", but rather ...\n\nYup, I guess that makes three of us?\n\n> I think that we might want a new file where Git developers can\n> share best practices and custom workflows. Such a document could\n> help contributors optimize their process to their own tastes based\n> on the experience of others. I can see a long list of integrations\n> with editors fitting in there, along with tips like \"create a RAM\n> disk for running tests\".\n>\n> My proposed name for such a file is \"WorkingOnGit\" but it's not\n> fantastic. Suggestions welcome.\n\nSounds like a good thing to have, but would there truly be hints and\ntips so specific to this project, I have to wonder. I do not think\nwe are in the business of making \"how to hack on and debug a project\ncode that is mostly written in C and whose history is managed in\nGit\" tutorial for each IDE, so I am not sure how well it would fly\n(not opposed to, but skeptical).\n\n> Cogoni: In conclusion, I think that if you remove the change to\n> MyFirstContribution.txt, then your patch can be merged pretty\n> quickly (probably, that's not my decision). I expect this discussion\n> about a potential \"WorkingOnGit\" file to continue, but if it comes\n> to fruition, your section on VS Code would be welcome.\n\nYeah, the change to that document did feel like it was working at a\ndifferent level from other changes.\n\nThanks.\n"},{"id":"453289","messageId":"20220407204001.112287-1-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"xmqqmtgwu9n7.fsf@gitster.g","subject":"[PATCH v4 0/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-07T20:40:00Z","receivedAt":"2022-04-07T20:46:23Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"Derrick Stolee writes:\n\n> Cogoni: In conclusion, I think that if you remove the change to\n> MyFirstContribution.txt, then your patch can be merged pretty\n> quickly (probably, that's not my decision). \n> I expect this discussion about a potential \"WorkingOnGit\" file to continue, \n> but if it come to fruition, your section on VS Code would be welcome.\n\nYes, I got the same conclusion, from the discussion between you and\nÆvar Arnfjörð Bjarmason. So, I remove the change to MyFirstContribution.txt.\nIt sounds like the best plan for now.\n\nBut, I agreed on some point with Ævar Arnfjörð Bjarmason, we have to try \nto recommending also free alternatives.\n\nAnd, yes, a new file is the best option. So, I keep my change somewhere, and \nI will come again with a new patch but not in its thread because it seems to \nbe out of the scope now.\n\n\n> Sounds like a good thing to have, but would there truly be hints and\n> tips so specific to this project, I have to wonder. I do not think\n> we are in the business of making \"how to hack on and debug a project\n> code that is mostly written in C and whose history is managed in\n> Git\" tutorial for each IDE, so I am not sure how well it would fly\n> (not opposed to, but skeptical).\n\nI think, it can help a newcomer, but not necessarily people with a \nlot of experience on various projects. But, we can give it a try and \nsee where it goes.\n\nThanks everyone for your reviews, your ideas and help.\n\n\nCOGONI Guillaume (1):\n contrib/vscode/: debugging with VS Code and gdb\n\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 2 files changed, 5 insertions(+), 2 deletions(-)\n\nDiff-intervalle vs v3 :\n1: 0600ab64f8 ! 1: 59de991a2d contrib/vscode/: debugging with VS Code and gdb\n @@ Commit message\n Add useful links in contrib/vscode/README.md to help the user to\n configure VS Code and how to use the debugging feature.\n \n - Add a mention to the README and the init.sh in Documentation/\n - MyFirstContribution.txt and a part to convince a newcomer that VS Code\n - can be helpful.\n -\n Helped-by: Matthieu Moy \n Helped-by: Derrick Stolee \n Co-authored-by: BRESSAT Jonathan \n Signed-off-by: COGONI Guillaume \n \n - ## Documentation/MyFirstContribution.txt ##\n -@@ Documentation/MyFirstContribution.txt: against the appropriate GitGitGadget/Git branch.\n - If you're using `git send-email`, you can use it the same way as before, but you\n - should generate your diffs from `..` and base your work on\n - `` instead of `master`.\n -+\n -+[[Bonus-useful-tools]]\n -+== Bonus - useful tools\n -+\n -+=== Visual Studio Code (VS Code)\n -+\n -+The contrib/vscode/init.sh script creates configuration files that enable\n -+several valuable VS Code features. See contrib/vscode/README.md for more\n -+information on using the script.\n -+\n -+In particular, this script enables using the VS Code visual debugger, including\n -+setting breakpoints, logpoints, conditional breakpoints in the editor.\n -+In addition, it includes the ability to see the call stack, the line of code that\n -+is executing and more. It is possible to visualize the variables and their values\n -+and change them during execution.\n -+\n -+In sum, using the built-in debugger can be particularly helpful to understand\n -+how Git works internally.\n -+It can be used to isolate certain parts of code, with this you may be able to ask\n -+more precises question when you are stuck. (See getting-help sections).\n -\n ## contrib/vscode/README.md ##\n @@ contrib/vscode/README.md: code editor which runs on your desktop and is available for\n [Windows](https://code.visualstudio.com/docs/setup/windows),\n-- \n2.25.1\n\n"},{"id":"453290","messageId":"20220407204001.112287-2-cogoni.guillaume@gmail.com","threadId":"57610","inReplyTo":"20220407204001.112287-1-cogoni.guillaume@gmail.com","subject":"[PATCH v4 1/1] contrib/vscode/: debugging with VS Code and gdb","fromName":"COGONI Guillaume","fromEmail":"cogoni.guillaume@gmail.com","sentAt":"2022-04-07T20:40:01Z","receivedAt":"2022-04-07T20:46:25Z","isPatch":true,"sender":{"key":"cogoni.guillaume@gmail.com","avatar":"https://avatars.githubusercontent.com/u/60919643?v=4"},"body":"The externalConsole=true setting is broken for many users (launching the\ndebugger with such setting results in VS Code waiting forever without\nactually starting the debugger). Also, this setting is a matter of user\npreference, and is arguably better set in a \"launch\" section in the\nuser-wide settings.json than hardcoded in our script. Remove the line to\nuse VS Code's default, or the user's setting.\n\nAdd useful links in contrib/vscode/README.md to help the user to\nconfigure VS Code and how to use the debugging feature.\n\nHelped-by: Matthieu Moy \nHelped-by: Derrick Stolee \nCo-authored-by: BRESSAT Jonathan \nSigned-off-by: COGONI Guillaume \n---\n contrib/vscode/README.md | 6 +++++-\n contrib/vscode/init.sh | 1 -\n 2 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/vscode/README.md b/contrib/vscode/README.md\nindex 8202d62035..f383c95e1f 100644\n--- a/contrib/vscode/README.md\n+++ b/contrib/vscode/README.md\n@@ -6,7 +6,11 @@ code editor which runs on your desktop and is available for\n [Windows](https://code.visualstudio.com/docs/setup/windows),\n [macOS](https://code.visualstudio.com/docs/setup/mac) and\n [Linux](https://code.visualstudio.com/docs/setup/linux). Among other languages,\n-it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools).\n+it has [support for C/C++ via an extension](https://github.com/Microsoft/vscode-cpptools) with\n+[debugging support](https://code.visualstudio.com/docs/editor/debugging)\n+\n+To get help about \"how to personalize your settings\" read:\n+[How to set up your settings](https://code.visualstudio.com/docs/getstarted/settings)\n \n To start developing Git with VS Code, simply run the Unix shell script called\n `init.sh` in this directory, which creates the configuration files in\ndiff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh\nindex 27de94994b..f139fd8644 100755\n--- a/contrib/vscode/init.sh\n+++ b/contrib/vscode/init.sh\n@@ -271,7 +271,6 @@ cat >.vscode/launch.json.new <