On Thu, Dec 3, 2015 at 9:53 PM, Max Kirillov <m...@max630.net> wrote: > On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote: >> On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov <m...@max630.net> wrote: >>> Using builtin defaults might be confusing for users - >>> editing the info/config.worktree they must keep in mind the >>> list of defaults (which they seem to don't know). >> >> All per-worktree variables are marked so in config.txt > > If I were user I would like the list to be more explicit.
I wouldn't. I mean, I have more than a dozen of git repos lying around, some I don't even remember where. Should I check git release notes at every upgrade then fix up _all_ of my repos? That's something I rather not do. >>> Also, if >>> anybody wants to extend the default list (like myself, for >>> submodules), should they edit the info/config.worktree in >>> provided template of extend the builtin list? What was wrong >>> with the default in template? >> >> Suppose you introduce a new >> per-worktree variable in the new git version. If it's in the builtin >> list, we don't have to update every repo's info/config,worktree. > > But how do you see it? Let's, for example, git-N consider > some variable as per-repository, and user does have it their > .git/config. Then git-N+1 considers it as per-worktree. How > does it find the variable while opening some existing > worktree? Then, if user sets the variable in some worktree > using git-N+1, git-N will no longer be able to see the > correct variable value. Does this mean that any change in > builtin list should cause repository incompatibility? Behavior differences between git versions have been alway will always be the problem. Yes providing some forward compatibility (by storing some logic outside the binary in this case) helps, but I don't think it eliminates it. If incompatibilities may lead to a big problem, then we can always make the new behavior an "repo extension" to stop older binaries from accessing the touched repos. Most of the time there's only one git version being used. So it should not be a big problem. But yes, if a repo is shared over network, then multiple git versions accessing the same repo can happen. On Thu, Dec 3, 2015 at 8:52 PM, Junio C Hamano <gits...@pobox.com> wrote: > I agree with your reasoning to have built-in set of files that are > per-worktree. I actually prefer *not* to have any configurability > to avoid confusion between users. There are a set of variables where whether they are shared or per-worktree is pretty much preference. For example, core.ignoreCase. What if I put one worktree on that case-insensitive file system? This gives the user some flexibility in managing those variables. _But_ they can also manage another way with include.path (or a new variant that is worktree-aware), with a bit of work. So killing info/core.worktree is not a bad idea. Even better, we can avoid pulling exclude machinery in. But yeah, need to sort out the upgrade issue Max mentioned first. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
