| Age | Commit message (Collapse) | Author |
|---|
|
In 046e1117d5 (templates: add .gitattributes entry for sample hooks,
2026-02-13) we have added another pattern to our EditorConfig that sets
the style for our hook templates. As our templates are located in
"templates/hooks/", we explicitly specify that subdirectory as part of
the globbing pattern.
This change causes files in other subdirectories, like for example
"builtin/add.c", to not be configured properly anymore. This seems to
stem from a subtlety in the EditorConfig specification [1]:
If the glob contains a path separator (a / not inside square
brackets), then the glob is relative to the directory level of the
particular .editorconfig file itself. Otherwise the pattern may also
match at any level below the .editorconfig level.
What's interesting is that the _whole_ expression is considered to be
the glob. So when the expression used is for example "{*.c,foo/*.h}",
then it will be considered a single glob, and because it contains a path
separator we will now anchor "*.c" matches to the same directory as the
".editorconfig" file.
Fix this issue by splitting out the configuration for hook templates
into a separate section. It leads to a tiny bit of duplication, but the
alternative would be something like the following (note the "{,**/}"):
[{{,**/}*.{c,h,sh,bash,perl,pl,pm,txt,adoc},config.mak.*,{,**/}Makefile,templates/hooks/*.sample}]
indent_style = tab
tab_width = 8
This starts to become somewhat hard to read, so the duplication feels
like the better tradeoff.
[1]: https://spec.editorconfig.org/#glob-expressions
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Acked-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The sample hooks are shell scripts but the filenames end with ".sample"
so they need their own .gitattributes rule. Update our editorconfig
settings to match the attributes as well.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Both files in the command below appear to be indented with tabs, and I'd
expect .bash files to have roughly the same style as .sh files.
$ find . -name \*.bash
./contrib/completion/git-completion.bash
./ci/check-directional-formatting.bash
Signed-off-by: David Mandelberg <david@mandelberg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The .adoc extension is commonly used for AsciiDoc files. In a future
commit, we'll update some files to switch from the .txt extension to the
.adoc extension, so update the EditorConfig file to use the same
configuration for both extensions, since we want the files to be
formatted completely identically whether they're using the older or
newer extension.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The Makefile and makefile fragments use the same indent style than the
rest of the code (with some inconsistencies).
Add them to the relevant .editorconfig section to make life easier for
editors and reviewers.
Signed-off-by: Max Gautier <mg@max.gautier.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Previously, the .editorconfig did not specify an indentation style for
text files. However, a quick look for indentation-like spacing suggest
that tabs are more common for documentation:
$ git grep -Pe '^ {4}' -- '*.txt' |wc -l
2683
$ git grep -Pe '^\t' -- '*.txt' |wc -l
14011
Note that there are a lot of files that indent list continuations (and
other things) with a single space -- if the first search was made
without the fixed quantifier the result would look very different.
However, the result does correspond with my anecdotal experience when
editing git documentation.
This commit adds *.txt to .editorconfig as an extension that should be
indented with tabs.
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Now that we have two places where we set code formatting settings,
.editorconfig and .clang-format, it's possible that they could fall out
of sync. This is relatively unlikely, since we're not likely to change
the tab width or our preference for tabs, but just in case, add comments
to both files reminding future developers to keep them in sync.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Contributors to Git use a variety of editors, each with their own
configuration files. Because C lacks the defined norms on how to indent
and style code that other languages, such as Ruby and Rust, have, it's
possible for various contributors, especially new ones, to have
configured their editor to use a style other than the style the Git
community prefers.
To make automatically configuring one's editor easier, provide an
EditorConfig file. This is an INI-style configuration file that can be
used to specify editor settings and can be understood by a wide variety
of editors. Some editors include this support natively; others require
a plugin. Regardless, providing such a file allows users to
automatically configure their editor of choice with the correct settings
by default.
Provide global settings to set the character set to UTF-8 and insert a
final newline into files. Provide language-specific settings for C,
Shell, Perl, and Python files according to what CodingGuidelines already
specifies. Since the indentation of other files varies, especially
certain AsciiDoc files, don't provide any settings for them until a
clear consensus forward emerges.
Set the line length for commit messages to 72 characters, which is the
generally accepted line length for emails, since we send patches by
email.
Don't specify an end of line type. While the Git community uses
Unix-style line endings in the repository, some Windows users may use
Git's auto-conversion support and forcing Unix-style line endings might
cause problems for those users.
Finally, leave out a root directive, which would prevent reading other
EditorConfig files higher up in the tree, in case someone wants to set
the end of line type for their system in such a file.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
