From: COGONI Guillaume <cogoni.guillaume@gmail.com>
To: matthieu.moy@univ-lyon1.fr
Cc: cogoni.guillaume@gmail.com, derrickstolee@github.com,
git.jonathan.bressat@gmail.com, git@vger.kernel.org,
gitster@pobox.com, guillaume.cogoni@gmail.com,
shaoxuan.yuan02@gmail.com
Subject: [PATCH v3 0/1] Documentation/ToolsForGit.txt: Tools for developing Git
Date: Wed, 20 Apr 2022 15:06:16 +0200 [thread overview]
Message-ID: <20220420130617.41296-1-cogoni.guillaume@gmail.com> (raw)
In-Reply-To: <c6b48fba-c950-bb3a-3fdb-6d420a4cdfbc@univ-lyon1.fr>
MOY Matthieu wrote:
> I think you can just drop that sentence. For someone a bit familiar with
> either VS code or any other IDE, it's no big surprise that the debugger
> integration allows such feature. For someone not familiar with VS code,
> the patch about to land in next already contains a link to a page
> explaining that.
Finally, I drop that sentence, I also think that the link that I put in
contrib/vscode/README is sufficient.
> contrib/emacs was really not meant for developers hacking on Git. Since
> it contains only pointers to obsolete stuff, we may want to just discard
> its current content and make it the place to put documentation for
> people hacking on Git with Emacs, just like contrib/vscode/ is for VS
> code and Git. But we probably have only a few (tens of) lines of
> documentation, so adding the doc directly in ToolsForGit.txt is probably
> better.
I left everything as they were. I just add the configuration lines directly
in ToolsForGit.txt because there is not a lot of line.
But, in the future, if there is more line, it would be better to move all of this
in the contrib/emacs/README.
> A good indicator, yes. But reading only the summary ...
I take the summary that you propose, so this not a criterion now.
> I agree that removing Emacs-specific code from a general document is
> nice, but then you should replace it with a link to ToolsForGit.txt like
> "Tips to make your editor follow this style can be found in
> ToolsForGit.txt" (without being specific to Emacs, that's the point of
> the document, it also applies to VS code and may be extended in the
> future to other editors).
Yup, I fix this, I add a mention to Documentation/ToolsForGit.txt in CodingGuideline.
I add it at the end of the file.
Thanks for your review,
COGONI Guillaume.
COGONI Guillaume (1):
Documentation/ToolsForGit.txt: Tools for developing Git
Documentation/CodingGuidelines | 18 +++++-------
Documentation/Makefile | 1 +
Documentation/ToolsForGit.txt | 51 ++++++++++++++++++++++++++++++++++
3 files changed, 59 insertions(+), 11 deletions(-)
create mode 100644 Documentation/ToolsForGit.txt
Interdiff versus v2 :
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index a7d21d6f6b..509cd89aa2 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -722,3 +722,10 @@ Writing Documentation:
inline substituted text+ instead of `monospaced literal text`, and with
the former, the part that should not get substituted must be
quoted/escaped.
+
+
+Documentation/ToolsForGit.txt:
+
+ This document collects tips, scripts, and configuration files to help
+ contributors working with the Git codebase use their favorite tools while
+ following the Git coding style.
diff --git a/Documentation/ToolsForGit.txt b/Documentation/ToolsForGit.txt
index dc370a5861..5060d0d231 100644
--- a/Documentation/ToolsForGit.txt
+++ b/Documentation/ToolsForGit.txt
@@ -5,8 +5,9 @@ Tools for developing Git
[[summary]]
== Summary
-This document aims to gather tools that have a README and/or scripts in
-the Git project.
+This document gathers tips, scripts and configuration file to help people
+working on Git's codebase use their favorite tools while following Git's
+coding style.
[[author]]
=== Author
@@ -29,6 +30,8 @@ information on using the script.
[[emacs]]
=== Emacs
+This is adapted from Linux's suggestion in its CodingStyle document:
+
- To follow rules of the CodingGuideline, it's useful to put the following in
GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
----
@@ -41,36 +44,8 @@ GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
(cperl-merge-trailing-else . t))))
----
-- The version for C:
-----
-(defun c-lineup-arglist-tabs-only (ignored)
- "Line up argument lists by tabs, not spaces"
- (let* ((anchor (c-langelem-pos c-syntactic-element))
- (column (c-langelem-2nd-pos c-syntactic-element))
- (offset (- (1+ column) anchor))
- (steps (floor offset c-basic-offset)))
- (* (max steps 1)
- c-basic-offset)))
-
-(add-hook 'c-mode-common-hook
- (lambda ()
- ;; Add kernel style
- (c-add-style
- "linux-tabs-only"
- '("linux" (c-offsets-alist
- (arglist-cont-nonempty
- c-lineup-gcc-asm-reg
- c-lineup-arglist-tabs-only))))))
-
-(add-hook 'c-mode-hook
- (lambda ()
- (let ((filename (buffer-file-name)))
- ;; Enable kernel mode for the appropriate files
- (when (and filename
- (string-match (expand-file-name "~/src/linux-trees")
- filename))
- (setq indent-tabs-mode t)
- (setq show-trailing-whitespace t)
- (c-set-style "linux-tabs-only")))))
-----
+For a more complete setup, since Git's codebase uses a coding style
+similar to the Linux kernel's style, tips given in Linux's CodingStyle
+document can be applied here too.
+==== https://www.kernel.org/doc/html/v4.10/process/coding-style.html#you-ve-made-a-mess-of-it
--
2.25.1
next prev parent reply other threads:[~2022-04-20 13:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-12 20:25 [PATCH 0/1] documentation: guide of best practices for GIT developer COGONI Guillaume
2022-04-12 20:25 ` [PATCH 1/1] " COGONI Guillaume
2022-04-13 14:36 ` [PATCH 0/1] " Shaoxuan Yuan
2022-04-13 16:36 ` Guillaume Cogoni
2022-04-16 12:34 ` [PATCH v1 0/1] Documentation/ToolsOnGit.txt: gather information about tools COGONI Guillaume
2022-04-16 12:34 ` [PATCH v1 1/1] " COGONI Guillaume
[not found] ` <63d7dc69656e47f7bc7bce4839711f32@SAMBXP02.univ-lyon1.fr>
2022-04-16 13:25 ` Matthieu Moy
2022-04-16 14:51 ` Philip Oakley
2022-04-16 17:11 ` Junio C Hamano
2022-04-17 9:35 ` [PATCH v2 0/1] Documentation/ToolsForGit.txt: Tools for developing Git COGONI Guillaume
2022-04-17 9:35 ` [PATCH v2 1/1] " COGONI Guillaume
[not found] ` <33d2087c66e44037b03db818dae60fea@SAMBXP02.univ-lyon1.fr>
2022-04-17 12:25 ` [PATCH v2 0/1] " Matthieu Moy
2022-04-20 13:06 ` COGONI Guillaume [this message]
2022-04-20 13:06 ` [PATCH v3 1/1] " COGONI Guillaume
2022-04-20 21:23 ` Junio C Hamano
2022-04-21 8:45 ` [PATCH v4 0/1] " COGONI Guillaume
2022-04-21 8:45 ` [PATCH v4 1/1] " COGONI Guillaume
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220420130617.41296-1-cogoni.guillaume@gmail.com \
--to=cogoni.guillaume@gmail.com \
--cc=derrickstolee@github.com \
--cc=git.jonathan.bressat@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=guillaume.cogoni@gmail.com \
--cc=matthieu.moy@univ-lyon1.fr \
--cc=shaoxuan.yuan02@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).