Issue #16112 has been updated by k0kubun (Takashi Kokubun).


Thanks for your comment, Jeremy. Your opinion makes sense except:

> 2) I'm against this. If we do keep the "expand tabs", then it should be applied to modified lines as well as new lines, so that we move in the direction of fewer tabs.

Can you tell me what problem you want to solve by not taking this option, compared to the current situation (not other options)? I do think both the current situation and option 2 solve the problem that "we move in the direction of fewer tabs", so I just failed to interpret your reasoning.

In my understanding, option 2 is a weaker version or a subset of option 0. Therefore, if you agree with option 0 but disagree with option 2, you or I may not be understanding how the other thinks. 

Whenever we make a commit which adds new lines, which is the case for many of our commits, option 2 will increase the ratio of space-indented lines in the repository. In that sense it helps "we move in the direction of fewer tabs" for sure. Some commits are not reducing the number of tab-indented lines, but is that different from the current "expand tabs"?

By combining option 3 with the current "expand tabs" behavior (changing indentation of changed lines to spaces as well, probably you felt it's not the case with option 2? If so, it's not my intention) and option 2 with the weaker "expand tabs" behavior, I believe we can move in the direction of fewer tabs for sure.

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

* 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/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>