ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: mame@ruby-lang.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:94430] [Ruby master Misc#16112] Reduce the possibility of "expand tabs" commit occurrences
Date: Mon, 19 Aug 2019 08:42:36 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-80855.20190819084236.2b36666f321cc531@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16112.20190819080927@ruby-lang.org

Issue #16112 has been updated by mame (Yusuke Endoh).


My (weak) vote goes to 1, or 0 (just drop "expand tabs" :-).

----------------------------------------
Misc #16112: Reduce the possibility of "expand tabs" commit occurrences
https://bugs.ruby-lang.org/issues/16112#change-80855

* Author: k0kubun (Takashi Kokubun)
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
## Problem
* While we agreed to use only spaces for indentation 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 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.



-- 
https://bugs.ruby-lang.org/

  parent reply	other threads:[~2019-08-19  8:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-16112.20190819080927@ruby-lang.org>
2019-08-19  8:09 ` [ruby-core:94428] [Ruby master Misc#16112] Reduce the possibility of "expand tabs" commit occurrences takashikkbn
2019-08-19  8:42 ` mame [this message]
2019-08-19  9:12 ` [ruby-core:94431] " shyouhei
2019-08-19 18:46 ` [ruby-core:94438] " XrXr
2019-08-20  8:26 ` [ruby-core:94444] " jean.boussier
2019-08-21 13:12 ` [ruby-core:94457] " takashikkbn
2019-08-21 13:59 ` [ruby-core:94458] " takashikkbn
2019-08-21 14:51 ` [ruby-core:94460] " merch-redmine
2019-08-21 15:18 ` [ruby-core:94461] " takashikkbn
2019-08-21 15:55 ` [ruby-core:94462] " merch-redmine
2019-08-22  5:03 ` [ruby-core:94474] " duerst
2019-08-22 11:24 ` [ruby-core:94477] " takashikkbn
2019-08-22 13:13 ` [ruby-core:94484] " takashikkbn

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-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-80855.20190819084236.2b36666f321cc531@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).