Re: Recommend these .gitconfig settings for git integrity.

[Óscar Fuentes]

Karl Fogel <address@hidden> writes:

> 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/.git/config is in my machine, I work with that repo and if
something breaks, I must deal with it, not you. Even if the changes
themselves does not cause any breakage, as soon as I have some other
issue and look at .git/config I'll see those changes; finding those
settings there will cause suspicion and distract me from fixing the real
problem.

> 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?

*If* the config changes are *required*, I'm all for it, giving the
developer a prominent notice. But what is at stake here is something
very different. You found something that looks like a "something
sensible for the cautious" feature type, and Paul is imposing it on
everyone's Emacs repo. The Emacs developement doesn't need that setting
at all, nor it affects the regular Emacs hacker, who only communicates
with the upstream Emacs repo. And if you worry about the possibility of
the upstream Emacs repo being tainted, just enable the checking on some
build bots (and/or on your machine).

> 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?

The Emacs developers as a group are entitled to have a say on what is
accepted on the upstream repo, but never on unilaterally changing how my
Emacs repo is configured.

> 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?

See above.

> 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.

I think that, given how it was implemented, this change is bad on
itself, and establishes a bad precedent. See my reply to Paul for some
ideas about how to improve the implementation. Requiring from the user
an informed consent is the right thing here. After all, if you convince
the user about the convenience of those settings, maybe he will apply
them on his other repos, which is a much better outcome from your POV, I
guess.

[snip]