Re: [PATCH] editorconfig: add Makefiles to "text files"

[Junio C Hamano <gitster@pobox.com>]

Max Gautier <mg@max.gautier.name> writes:

> The Makefile and makefile fragments use the same indent style than the
> rest of the code (with some inconsistencies).
>
> Add them to the relevant .editorconfig section to make life easier for
> editors and reviewers.
>
> Signed-off-by: Max Gautier <mg@max.gautier.name>
> ---
>  .editorconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.editorconfig b/.editorconfig
> index f9d819623d..15d6cbeab1 100644
> --- a/.editorconfig
> +++ b/.editorconfig
> @@ -4,7 +4,7 @@ insert_final_newline = true
>  
>  # The settings for C (*.c and *.h) files are mirrored in .clang-format.  Keep
>  # them in sync.
> -[*.{c,h,sh,perl,pl,pm,txt}]
> +[{*.{c,h,sh,perl,pl,pm,txt},config.mak.*,Makefile}]
>  indent_style = tab
>  tab_width = 8

A question out of curiosity (because the answer does not affect any
conclusion): Does editorconfig attempt to cover any non-text files?

Two more questions that do affect the conclusions are:

 * Among the files we ship (i.e. "git ls-tree -r HEAD") and edit
   with editors that honor .editorconfig settings, are there any
   file that we do not want tab indentation other than *.py?

 * Does .editorconfig file allow possibly conflicting setting, with
   a reliable conflict resolution rules?

What I am trying to get at is if it is possible to make something
along this line to work:

    [*]
	charset = utf-8
	insert_final_newline = true
	indent_style = tab
	tab_width = 8
    [*.py]
	indent_style = space
	indet_size = 4

I am assuming, without knowing, that the conflict resolution rule
may be "for the same setting, the last match wins" so by default we
always use "indent_style = tab", but if we are talking about a Python
script, it is overruled with "indent_style = space".

If that is possible, we do not have to keep adding "ah, files that
match this pattern are also text", i.e., everything is text and
indented by tab, unless specified otherwise.

Thanks.