Re: Recommend these .gitconfig settings for git integrity.

[Karl Fogel]

Óscar Fuentes <address@hidden> writes:
>There is nothing Emacs-specific on those settings, so this argument is
>not valid.
>
>Paul and Karl: I know you are doing this on good faith and I appreciate
>your efforts, but this approach of changing the .git/config file (and
>the emacs' .git/config file is also on my system, Karl) is a bit
>worrying. If the change produces some side-effect, it's the user who is
>in charge of investigating what's going on and imagine his surprise
>when, after looking at .git/config in desperation, he sees it edited.
>
>>> The Emacs build process has no bussiness on sneaking config changes that
>>> affects how tools work on my system
>>
>> Yes, the developer should be told. This was already done for Git
>> hooks, but I forgot to do it for Git configuration settings. I fixed
>> that by installing the attached patch into emacs-25.
>
>Thanks, but I would prefer a `make' target or script and a mention on
>CONTRIBUTING about all the good it will cause if the user ever decides
>to execute it.

Hmmm.  I know of no way to resolve what is essentially a difference in taste.  
It would bother me if emacs/autogen.sh made changes to my global ~/.gitconfig, 
but it doesn't bother me if it makes changes to emacs/.git/config.  Whereas you 
are bothered in both cases.

Emacs's autogen.sh already does things that cause a permanent difference in the 
behavior of, say, the 'configure' and 'make' tools when run in the Emacs tree.  
Why should autogen.sh not do the same for the 'git' tool when run in the Emacs 
tree?  Is there some reason why the Emacs developers as a group can't decide 
that integrity-checking should be turned on for git data transfers?  After all, 
if the developer group decided that some sort of integrity checking should be 
turned on by default for the build process itself, we wouldn't have any problem 
with that.  In other words, how is this really different?

However, I'm pretty sure you thought of all those arguments already, and are 
just not convinced by them.  It's Paul's commits in question, so I don't feel 
I'm in the hot seat for deciding whether or not to revert them :-).  But FWIW I 
think they are a good idea, and are consistent with principles we'd use for 
deciding how any other tool should behave when invoked on the Emacs source tree.

(In any case, the documentation changes I'm making are not affected by this.)

Best regards,
-Karl