Re: Recommend these .gitconfig settings for git integrity.

[Óscar Fuentes]

Paul Eggert <address@hidden> writes:

> On 02/02/2016 07:49 AM, Óscar Fuentes wrote:
>
>> I mean, it look like it does a good thing, if you read the
>> description. So why it is not activated by default? Maybe it has some
>> drawbacks.
> Yes, it has a drawback. I mentioned it in my previous message. On some
> larger projects, it slows down some git operations. However, this does
> not seem to be a significant problem with Emacs development.

Care to explain this in more detail? Emacs is no small project. If the
slow down affects large transfers ("large" meaning either many objects
or big objects) what happens if an Emacs hackers pauses his activity for
several months and then pulls? (after monitoring emacs-diffs for several
years, I can attest that this scenario is quite frequent.)

> In contrast, omitting the option can cause significant problems later,
> problems that can be hard to discover and even harder to repair. For
> an example of this, please see the following bugreport on GitHub:
>
> https://github.com/wp-cli/php-cli-tools/issues/70
>
> Apparently the wp-cli project has a corrupted Git history that could
> have been prevented by the new setting. It is so much trouble to fix
> this that the project's maintainer and the GitHub staff think that
> fixing it is more trouble than it's worth, and will just live with the
> corrupted repository. I'd hate to see the same thing happen to the
> Emacs source code repository.

So the GitHub folks, on their early days, had a bug on their Git
re-implementation and caused some hosted project to become "infected".
This looks like a far-fetched case from the Emacs POV. If we wish to
avoid tainted objects created by whatever cause, the check can be
enabled on the Savannah's repo, hence limiting the problem to the
"infected" user. The problem seems to be so rare that a single Emacs
hacker experiencing it every decade or so (if it ever happens) doesn't
warrant the risks and inconveniences associated with using the setting
(see my previous messages.)

>> Anyone cared about that possibility, apart from the "I
>> activated it and so far, so good" testimony from*one*  individual?
>
> I've been using it. So has Stefan, and Karl. Nobody who has used it
> has reported problems. If there were real problems with this option we
> should not make it the default.

So you, Karl and Stefan used the feature... for how much time? Two days?
Are you a reprensetative sample of the overwhelming majority of the
Emacs devel populationt? (No, you aren't). Sorry but imposing the config
change to everybody's repo so soon and without discussion looks like a
mindlessly hurried-up move, to say it bluntly.

> I will look into modifying autogen.sh to make this flag optional,
> since there seems to be significant opposition to it.

Thanks, although it is now a bit late. It is already installed on
several repos, for sure. And anybody that stumbles on the revisions that
contained your change (by bisecting some bug, for example) will have his
.git/config file modified. I'm pretty sure that you didn't think of this
issues when you made the change (neither I did at first.)

> I still don't
> understand why there's so much opposition, though. If the Emacs
> repository becomes corrupted because this option was omitted, quite
> possibly we won't notice, and even if we notice quite possibly we
> won't fix it. I would hate to see that happen.

I appreciate your concern but that has an easy solution: enable it on
the server (and on your own machine, to be extra sure.) See, problem
solved. Now that you are at it, convince the Savannah admins to enable
the check on all git repos they host. That is much more reasonable than
automatically changing the configuration of each clone out there.