On Thu, Mar 03, 2016 at 08:08:40PM +0700, Duy Nguyen wrote: > On Tue, Mar 1, 2016 at 9:40 PM, Jeff King <peff@xxxxxxxx> wrote: > > There's a chicken-and-egg problem with using the regular > > git_config during the repository setup process. We get > > around it here by using a special interface that lets us > > specify the per-repo config, and avoid calling > > git_pathdup(). > > > > But this interface doesn't actually make sense. It will look > > in the system and per-user config, too; we definitely would > > not want to accept a core.repositoryformatversion from > > there. > > > > The git_config_from_file interface is a better match, as it > > lets us look at a single file. > > Let's see. We look at core.worktree, core.bare, > core.repositoryformatversion, and extensions.* in this code. The first > three should definitely per-repo (and should be mentioned in the > commit as well). But what about the last one? Any possible use case > that wants to enable, say extensions.preciousobjects, for all repos? > Yes we would need to switch core.repo..version to 1 to take effect, > but that does not actually eliminate this case.. just thinking out > loud... I thought about that; a more likely use is to set extensions.refStorage once it exists, to use your preferred backend everywhere. But it _has_ to match what's in the repository's on-disk format. Setting it in your ~/.gitconfig is going to break all of your existing repositories using another backend. So the right thing is to have init.refStorage or something, and have init/clone default to that when creating the repo, and set up the correct extensions.refStorage config _and_ set up the on-disk ref storage to match. -Peff -- 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