[PATCH v1 0/1] Documentation/ToolsOnGit.txt: gather information about tools

[COGONI Guillaume <cogoni.guillaume@gmail.com>]

I decide to change my approach with this patch, and now I agreed at some 
point with <shaoxuan.yuan02@gmail.com>, 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