From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.7 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 5DB231F461 for ; Wed, 21 Aug 2019 13:12:38 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 350241209F5; Wed, 21 Aug 2019 22:12:30 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 050B21209D6 for ; Wed, 21 Aug 2019 22:12:26 +0900 (JST) Received: by filter0138p3mdw1.sendgrid.net with SMTP id filter0138p3mdw1-16838-5D5D433D-C 2019-08-21 13:12:29.165041627 +0000 UTC m=+329806.847430651 Received: from herokuapp.com (unknown [54.226.103.57]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id FzUhDBmmSfyk-ac_UX0zUQ for ; Wed, 21 Aug 2019 13:12:29.141 +0000 (UTC) Date: Wed, 21 Aug 2019 13:12:29 +0000 (UTC) From: takashikkbn@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70006 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16112 X-Redmine-Issue-Author: k0kubun X-Redmine-Sender: k0kubun X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?9bN4wU0cxWeLAEOz6NELGbwCNAokUg6cnjH8nvx=2FqgZNC3JY9ElaI6Bm5UnWz=2F?= =?us-ascii?Q?dEQlsPmMridPF4U95NT+EZNtnJGg3fd4fQP7UjT?= =?us-ascii?Q?I7Q5vlhSiqPmxHjnhNQucP=2FQMXZF6S3b9JNlfpl?= =?us-ascii?Q?kmDFSCgEwuNTKPNs+4ricslV=2Fiz10nWQqF9Au9q?= =?us-ascii?Q?OOSs7bDBJuU7nHiZsrK5+zQygBiAKfiDXwA=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94457 Subject: [ruby-core:94457] [Ruby master Misc#16112] Reduce the possibility of "expand tabs" commit occurrences X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16112 has been updated by k0kubun (Takashi Kokubun). > I would love it if (1) can happen. > > Mostly a minor annoyance, to be sure, and perhaps C programmers don't use these editors. However, it's something worth considering. > > I second what Alan said, editing Ruby source with my editor is a nightmare. Despite the Vim's default behavior which shows the mixed indentation well, my Vim configuration had shown it weirdly (well, I couldn't find the reason to keep the config now, so I fixed it today actually), and I've put `.vimrc.local` whenever I git-clone ruby.git to correct that. It'd be bothering for people having such configuration in both Emacs and Vim too. > I wonder wether git filter-branch was considered. > > It would allow to fix the formatting while keeping a clean history, the downside being that all commit shas would change. Making most of shas different would be more problematic than polluting `git blame` (without -w) because we can't update all of the references to commits in the past. We'd have a control of commit messages and redmine contents, but there are many third-party projects linking Ruby commits, tweets, blog posts, conference talks, etc. ---------------------------------------- Misc #16112: Reduce the possibility of "expand tabs" commit occurrences https://bugs.ruby-lang.org/issues/16112#change-80888 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- ## Problem * While we agreed to use only spaces for indentation of C code in [Bug #14246], we sometimes hit "expand tabs" commit when we just edit a part of existing lines with hard tab indentation. * "expand tabs" commit bothers people when we need to perform a revert or a backport. * However, because [Bug #14246] aimed to eventually make indentations consistent, we do not want to just drop "expand tabs". * One of the motivations to solve [Bug #14246] is that having hard tabs makes preprocessed MJIT header ugly and it makes debugging on GCC hard. As MJIT may introduce C-code inlining for sources outside vm.c in the future, we want to fix the issue in almost all C sources which can be run on runtime. ## Possible Solutions There would be some options to approach the problem. I'd like to hear opinions about these options. 1. Expand all tabs at once for all files managed by auto-style. * In [Bug #14246], this was clearly objected for the reason "Indents should become consistent over time". * In my understanding, not folliwng "Indents should become consistent over time" would be problematic mainly for polluting "git blame" and conflicts on backport. * For the first point, we can use `-w` option of `git blame` to ignore that. * For backport, it's a trade-off with many "expand tabs" commits. We need opinions about this from @usa and @nagachika . * Also reverting a commit before the commit expanding all tabs would be bothering, for a short while. 2. Skip expand tabs for existing lines when indentation is not changed, and expand tabs only in newly-added lines. * If editors are configured properly, "expand tabs" would not happen for new patches in this approach. * Even in this approach, at least we will not go to the opposite direction of eventually achieving [Bug #14246]. So it seems acceptable. 3. Prepare a local pre-commit hook to perform "expand tabs", and let people who do not want "expand tabs" use it. 4. Make pull request CI fail when there's diff to be expanded, and let people who do not want "expand tabs" commit things from pull requests. ---Files-------------------------------- Screen Shot 2019-08-19 at 2.43.06 PM.png (48.8 KB) -- https://bugs.ruby-lang.org/