Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > I don't understand why this breaks the test. It seems blame > --encoding=UTF-8 relies on the fact that the i18n section of the > configuration is not loaded. That's interesting; I haven't traced the codepath involved, but I do not think "configuration is not loaded" is the issue. "Reading either before the main codepath is ready, or more likely overwriting/destroying what the main codepath has read it by re-reading the configuration" may be. Perhaps the part that reads encoding configuration is busted and is not expected to be called way early or way late. In short, this patch introduces uncertainty that config reader is called at a random and unexpected (from the existing code's point of view) place in the codepath, and I wouldn't be very surprised if there are similar breakages introduced by it. What does the callchain look like when we bootstrap the attr stack for the first time with this patch applied? Have we already located where the git repository is? Has the main codepath that wants to read encoding settings read them? Has the main codepath already used the command line option that overrides the settings it obtained from the configuration file? Is the extra reading of the config destroying that data? I am afraid that your patch to narrow the parts of the config that is read from this codepath is only sweeping the problem under the rug, making the issue harder to diagnose. Wouldn't we see exactly the same issue if some codepath (other than blame) wants to see a core.* configuration not to be read in this codepath for whatever reason? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html