From: Max Gautier <mg@max.gautier.name>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Hans Jerry Illikainen <hji@dyntopia.com>
Subject: Re: [PATCH] editorconfig: add Makefiles to "text files"
Date: Sun, 24 Mar 2024 08:54:49 +0100 [thread overview]
Message-ID: <Zf_cSWY9DxVxKZu2@framework> (raw)
In-Reply-To: <xmqqr0g0yhoe.fsf@gitster.g>
On Sat, Mar 23, 2024 at 10:36:01AM -0700, Junio C Hamano wrote:
> >> * Does .editorconfig file allow possibly conflicting setting, with
> >> a reliable conflict resolution rules?
> >
> > Yeah it does: https://spec.editorconfig.org/#id8
> > TL;DR:
> > - from top to bottom, last matching section wins
> > - if multiple .editorconfig are found (up until one with the root key or
> > in /) closest to the file wins.
> >>
> >> What I am trying to get at is if it is possible to make something
> >> along this line to work:
> >>
> >> [*]
> >> charset = utf-8
> >> insert_final_newline = true
> >> indent_style = tab
> >> tab_width = 8
> >> [*.py]
> >> indent_style = space
> >> indet_size = 4
> >>
> >> I am assuming, without knowing, that the conflict resolution rule
> >> may be "for the same setting, the last match wins" so by default we
> >> always use "indent_style = tab", but if we are talking about a Python
> >> script, it is overruled with "indent_style = space".
> >
> > So it looks like it's possible, if we also add judiciously .editorconfig
> > in subdirectory where we have other files which don't want the same
> > settings, probably:
>
> That is much less than ideal---I was hoping that we can do this
> with just one file. My reading of that spec is that in the same
> file it would be the last one wins, so something line what I gave
> you above should work more-or-less as-is?
>
I read it the same way, I didn't intend to imply using one top level
only was not possible ; sorry for the lack of clarity.
> Also I am not sure if there is any reason why ...
>
> > - po/
> > - t/
> > - contrib/
> > - .github/
> > - ...
> >
> > Not sure if that's easier than adding stuff to the to the root config
> > though.
>
> ... t/*.sh should use rules different from those that apply to
> check-builtins.sh at the root level, or contrib/mw-to-git/*.perl
> should use Perl rules different from those that apply to
> perl/Git.pm. So I think "we need per-directory customization" is a
> red herring.
Oh, I was more thinking about the other stuff under t/ , not she scripts
themselves, there is some .test, .diff, lots of files without extensions
(some css apparently, among other stuff) , and without looking in
details, my best guess is that most of this is test samples (=> I mean
things used by the tests to compare / test processing result).
I don't know if that's supposed to be edited manually though.
But yeah, "per-directory customization" isn't good, it multiplies the
place to look when the config is not correct. I was mentioning by fear
that using only one file would be hard to manage is there is too much
patterns.
--
Max Gautier
next prev parent reply other threads:[~2024-03-24 7:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 22:17 [PATCH] editorconfig: add Makefiles to "text files" Max Gautier
2024-03-22 22:40 ` Junio C Hamano
2024-03-23 15:55 ` Max Gautier
2024-03-23 17:36 ` Junio C Hamano
2024-03-24 7:54 ` Max Gautier [this message]
2024-03-25 2:54 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zf_cSWY9DxVxKZu2@framework \
--to=mg@max.gautier.name \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hji@dyntopia.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.
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 NNTP newsgroup(s).