I decide to change my approach with this patch, and now I agreed at some point with <shaoxuan.yuan02@xxxxxxxxx>, GIT might not be the right place to talk about recommendation for best practice, tools or workflows. So, I change the file, it just gathers some links that point to tools that have a README or scripts in contrib/. Now, the idea is more like "Oh, you use this tool? Did you know that we have a README and some scripts to make it more simple to use along GIT, it might interest you." (e.g. see contrib/emacs.). It's just informative and no longer a recommendation. In addition, having a file that collects this type of information is more practical that have a tool mention in many files. And I hope that people who use other tools other than Emacs or Visual Studio Code, will be interesting for doing scripts and README in contrib/. Thanks and I hope this new approach is better, COGONI Guillaume Desmoniak (1): Documentation/ToolsOnGit.txt: gather information Documentation/Makefile | 1 + Documentation/ToolsOnGit.txt | 35 +++++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 Documentation/ToolsOnGit.txt Difference between v0 and v1 diff --git a/Documentation/Makefile b/Documentation/Makefile index 82badee19a..2fd73078f7 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -93,7 +93,7 @@ SP_ARTICLES += $(API_DOCS) TECH_DOCS += MyFirstContribution TECH_DOCS += MyFirstObjectWalk TECH_DOCS += SubmittingPatches -TECH_DOCS += WorkingOnGit +TECH_DOCS += ToolsOnGit TECH_DOCS += technical/bundle-format TECH_DOCS += technical/hash-function-transition TECH_DOCS += technical/http-protocol diff --git a/Documentation/ToolsOnGit.txt b/Documentation/ToolsOnGit.txt new file mode 100644 index 0000000000..a33b369a06 --- /dev/null +++ b/Documentation/ToolsOnGit.txt @@ -0,0 +1,35 @@ +Tools on GIT +============ +:sectanchors: + +[[summary]] +== Summary + +This document aims to gather tools that have a README and/or scripts in +the GIT project. + +[[author]] +=== Author + +The Git community. + +[[table_of_contents]] +== Table of contents + +- <<vscode>> +- <<emacs>> + +[[vscode]] +=== Visual Studio Code (VS Code) + +The contrib/vscode/init.sh script creates configuration files that enable +several valuable VS Code features. See contrib/vscode/README.md for more +information on using the script. + +In particular, this script enables using the VS Code visual debugger, including +setting breakpoints, logpoints, conditional breakpoints and more in the editor. + +[[emacs]] +=== Emacs + +See contrib/emacs/README for more information. diff --git a/Documentation/WorkingOnGit.txt b/Documentation/WorkingOnGit.txt deleted file mode 100644 index d324d9fcd8..0000000000 --- a/Documentation/WorkingOnGit.txt +++ /dev/null @@ -1,53 +0,0 @@ -Guide of the best practices and custom workflow -=============================================== -:sectanchors: - -[[summary]] -== Summary - -This book aims to put together a lot of useful tools, best practices and -custom workflows that might help the Git developer. - -[[author]] -=== Author - -The Git community. - -[[table_of_contents]] -== Table of contents - -- <<debuggers>> - -[[debuggers]] -== Using debuggers - -You'll probably find it useful to use a debugger to interactively inspect -your code as it's running. - -There's numerous such debuggers, and you may even have one installed -already along with your development toolchain. - -The GNU debugger (gdb) is probably the most common one command-line -debugger, along with the LLDB debugger (lldb): - -==== https://www.sourceware.org/gdb/ -==== https://lldb.llvm.org/ - -=== GUIs - -==== Visual Studio Code (VS Code) - -The contrib/vscode/init.sh script creates configuration files that enable -several valuable VS Code features. See contrib/vscode/README.md for more -information on using the script. - -In particular, this script enables using the VS Code visual debugger, including -setting breakpoints, logpoints, conditional breakpoints in the editor. -In addition, it includes the ability to see the call stack, the line of code that -is executing and more. It is possible to visualize the variables and their values -and change them during execution. - -In sum, using the built-in debugger can be particularly helpful to understand -how Git works internally. -It can be used to isolate certain parts of code, with this you may be able to ask -more precises question when you are stuck. 2.25.1
