From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Patrick Steinhardt <ps@pks.im>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
Eric Sunshine <ericsunshine@gmail.com>,
git@vger.kernel.org, Ezekiel Newren <ezekielnewren@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 2/6] ci: check formatting of our Rust code
Date: Wed, 29 Oct 2025 23:54:47 +0100 [thread overview]
Message-ID: <aQKbN157AMJi59rV@szeder.dev> (raw)
In-Reply-To: <xmqqms61h0g1.fsf@gitster.g>
On Wed, Oct 08, 2025 at 08:34:22AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> >> ... but I also think we should take this
> >> opportunity to choose the Rust defaults for Rust. C, Perl, and text
> >> formats like AsciiDoc do not have rigid defaults about indentation
> >> style, tabs vs. spaces, and line length; Rust does. We wouldn't use
> >> tabs in Rust (the default is four spaces) because we use it everywhere
> >> else, so I think we should take the opportunity to use the Rust defaults
> >> here as well.
> >
> > I am also slightly leaning into the direction of sticking with Rust's
> > default of 100 characters. It's not substantially more than 80, should
> > be reasonable to accommodate for in most modern setups, and sticks with
> > what the remainder of the ecosystem is doing.
> >
> > So for now I'll leave it at 80 characters. But I don't feel strongly
> > about this, so if there is a majority in favor of 80 characters I'm
> > happy to adjust.
>
> So the question is if we want consistency across files regardless of
> what language they are written in (i.e. 80-columns everywhere) or we
> treat our existing rules a "fallback rules" we have adopted while
> dealing with languages without their own strict rules, and use the
> default for a language with its own rule (i.e. whatever rustfmt
> wants is used for Rust, our own rules still apply to everything
> else)?
Consistency across files regardless of language was great, because I,
for one, prefer to use the same editor for all files regardless of
language.
I find 100 columns much worse than 80, because on my laptop I can put
three 80 columns editors next to each other (and still have a bit of
room to spare), but with 100 columns there is only room for two.
> I actually am fine with the latter myself.
>
> If people strongly prefer, I also can be talked into adopting
> slightly wider limit for our fallback rules for everything else, but
> that is probably a separate discussion. It is a bit unfriendly move
> against folks with aging eyeballs like myself, though.
>
> Thanks.
>
>
next prev parent reply other threads:[~2025-10-29 22:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 12:36 [PATCH 0/6] ci: improvements to our Rust infrastructure Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 1/6] ci: deduplicate calls to `apt-get update` Patrick Steinhardt
2025-10-07 12:54 ` Karthik Nayak
2025-10-14 20:56 ` Justin Tobler
2025-10-07 12:36 ` [PATCH 2/6] ci: check formatting of our Rust code Patrick Steinhardt
2025-10-07 13:04 ` Karthik Nayak
2025-10-07 13:50 ` Patrick Steinhardt
2025-10-07 17:13 ` Eric Sunshine
2025-10-07 17:38 ` Junio C Hamano
2025-10-07 18:03 ` Eric Sunshine
2025-10-07 22:42 ` brian m. carlson
2025-10-07 22:58 ` Chris Torek
2025-10-08 4:46 ` Patrick Steinhardt
2025-10-08 15:34 ` Junio C Hamano
2025-10-09 5:29 ` Patrick Steinhardt
2025-10-29 22:54 ` SZEDER Gábor [this message]
2025-10-07 22:07 ` brian m. carlson
2025-10-08 20:55 ` SZEDER Gábor
2025-10-09 5:29 ` Patrick Steinhardt
2025-10-29 21:19 ` SZEDER Gábor
2025-10-07 12:36 ` [PATCH 3/6] rust/varint: add safety comments Patrick Steinhardt
2025-10-08 0:29 ` brian m. carlson
2025-10-08 4:46 ` Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 4/6] ci: check for common Rust mistakes via Clippy Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 5/6] ci: verify minimum supported Rust version Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 6/6] rust: support for Windows Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 0/6] ci: improvements to our Rust infrastructure Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 1/6] ci: deduplicate calls to `apt-get update` Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 2/6] ci: check formatting of our Rust code Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 3/6] rust/varint: add safety comments Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 4/6] ci: check for common Rust mistakes via Clippy Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 5/6] ci: verify minimum supported Rust version Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 6/6] rust: support for Windows Patrick Steinhardt
2025-11-20 19:45 ` Ezekiel Newren
2025-11-21 8:18 ` Johannes Schindelin
2025-11-21 21:39 ` Junio C Hamano
2025-10-15 15:21 ` [PATCH v3 0/6] ci: improvements to our Rust infrastructure 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=aQKbN157AMJi59rV@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=ericsunshine@gmail.com \
--cc=ezekielnewren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ps@pks.im \
--cc=sandals@crustytoothpaste.net \
/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).