Issue #16112 has been updated by duerst (Martin D=FCrst). k0kubun (Takashi Kokubun) wrote: > * It would reduce the number of problems for editors like Sublime Text, V= SCode, and Atom. I'm surprised some of the currently most popular editors can't handle such = situations. I'm not using one of these editors, but would like to check how= the editors I use behave. For this, it would be good to know a file (and s= ome relevant line numbers) that currently has both tab-indented and space-i= ndented lines. Can somebody give an example? ---------------------------------------- Misc #16112: Reduce the possibility of "expand tabs" commit occurrences https://bugs.ruby-lang.org/issues/16112#change-80909 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: = ---------------------------------------- ## Problem * While we agreed to use only spaces for indentation of C code in [Bug #142= 46], we sometimes hit "expand tabs" commit when we just edit a part of exis= ting 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 consi= stent, we do not want to just drop "expand tabs". * One of the motivations to solve [Bug #14246] is that having hard tabs m= akes preprocessed MJIT header ugly and it makes debugging on GCC hard. As M= JIT may introduce C-code inlining for sources outside vm.c in the future, w= e 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 opini= ons 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 shou= ld become consistent over time". * In my understanding, not folliwng "Indents should become consistent ove= r 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 ignor= e 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 b= othering, 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 directio= n of eventually achieving [Bug #14246]. So it seems acceptable. 3. Prepare a local pre-commit hook to expand tabs in newly-added or edited = lines, and let people who do not want an "expand tabs" commit use it. 4. Make pull request CI fail when there's diff to be expanded, and let peop= le 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=3Dunsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>