Re: [PATCH 0/5] Split .git/config in multiple worktree setup
On Thu, Dec 3, 2015 at 9:53 PM, Max Kirillov 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 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 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
Re: [PATCH 0/5] Split .git/config in multiple worktree setup
On Thu, Dec 03, 2015 at 11:52:43AM -0800, Junio C Hamano wrote: > I actually prefer *not* to have any configurability > to avoid confusion between users. This could be an approach. But because of upgrade issues which I described in the other response it looks like this decision is not easy to change in a later version. So the list should be decided here and now for each existing variable, and later for any new one, and preferable never changed after that. -- Max -- 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
Re: [PATCH 0/5] Split .git/config in multiple worktree setup
On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote: > On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov 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. >> 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? With defaults written in the info/config.worktree file the issue do not exist at all: you can open repository created with a git version with some default list of per-worktree veriables with a version with other default list. It all would work. If user decides to change the actual list of default per-worktree variable it is always can be done explcitly, with some provided convenience command for example. -- Max -- 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
Re: [PATCH 0/5] Split .git/config in multiple worktree setup
Duy Nguyen writes: > If a variable _must_ be per-worktree or something will break, then it > should belong to the builtin list (so the user is less likely to mess > with it). If it may or may not be per-worktree, depending on one's > preference, then we can keep this in info/config.worktree. I made the > builtin list for that reason (user not breaking stuff accidentally) > and another one, which is upgrade issue. 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. 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. -- 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
Re: [PATCH 0/5] Split .git/config in multiple worktree setup
On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov wrote: > On Wed, Dec 02, 2015 at 08:13:41PM +0100, Nguyễn Thái Ngọc Duy wrote: >> Let's restart this. From the last discussion [1], we need to make >> core.worktree per-worktree for submodules to work. We also need >> core.sparseCheckout per-worktree. > > Thank you. It would be nice to have it, so that features > like submodules work fully. > > Now there are extensions support, would it make sense to > mark repositories which use per-worktree config with an > extension? It could clearly separate 2.5-style > multi-worktree repositories (which might exist already > around) from the new format. The extension could be set by > 'worktree add' while creating first worktree, for example. Hmm.. I didn't think of this. If we add this as a repo extension, then we could use git/config for shared vars only, main worktree specific vars can stay in .git/config.worktree while linked worktree's in .git/worktrees/*/config.worktree. Neat. >> This series adds a pattern list, with .gitignore syntax mostly, that >> split config var set into two sets, the per-worktree set will be >> stored in .git/worktrees/*/config.worktree instead. The pattern list >> consists of default patterns, built in git binary, and user ones in >> .git/info/config.worktree. > > 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 > 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? If a variable _must_ be per-worktree or something will break, then it should belong to the builtin list (so the user is less likely to mess with it). If it may or may not be per-worktree, depending on one's preference, then we can keep this in info/config.worktree. I made the builtin list for that reason (user not breaking stuff accidentally) and another one, which is upgrade issue. 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. -- 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
Re: [PATCH 0/5] Split .git/config in multiple worktree setup
On Wed, Dec 02, 2015 at 08:13:41PM +0100, Nguyễn Thái Ngọc Duy wrote: > Let's restart this. From the last discussion [1], we need to make > core.worktree per-worktree for submodules to work. We also need > core.sparseCheckout per-worktree. Thank you. It would be nice to have it, so that features like submodules work fully. Now there are extensions support, would it make sense to mark repositories which use per-worktree config with an extension? It could clearly separate 2.5-style multi-worktree repositories (which might exist already around) from the new format. The extension could be set by 'worktree add' while creating first worktree, for example. > This series adds a pattern list, with .gitignore syntax mostly, that > split config var set into two sets, the per-worktree set will be > stored in .git/worktrees/*/config.worktree instead. The pattern list > consists of default patterns, built in git binary, and user ones in > .git/info/config.worktree. 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). 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? -- Max -- 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
[PATCH 0/5] Split .git/config in multiple worktree setup
Let's restart this. From the last discussion [1], we need to make core.worktree per-worktree for submodules to work. We also need core.sparseCheckout per-worktree. This series adds a pattern list, with .gitignore syntax mostly, that split config var set into two sets, the per-worktree set will be stored in .git/worktrees/*/config.worktree instead. The pattern list consists of default patterns, built in git binary, and user ones in .git/info/config.worktree. I have marked a few obvious config vars as per-worktree. There may be more to mark, Max did go over them last time so I'll let him to add more if submodule needs it. [1] http://article.gmane.org/gmane.comp.version-control.git/266520 Nguyễn Thái Ngọc Duy (5): dir.c: clean the entire struct in clear_exclude_list() config.c: move worktree-specific variables to .git/worktrees/... setup.c: remove special case of core.worktree and core.bare worktree: make core.sparseCheckout and core.ignoreStat per-worktree git-worktree.txt: mention about the config file split Documentation/config.txt | 13 ++- Documentation/git-worktree.txt | 13 +++ Documentation/gitrepository-layout.txt | 12 +++ builtin/config.c | 9 ++ cache.h| 2 +- config.c | 153 +++-- dir.c | 6 +- dir.h | 1 + setup.c| 62 ++--- t/t2025-worktree-add.sh| 26 ++ 10 files changed, 250 insertions(+), 47 deletions(-) -- 2.2.0.513.g477eb31 -- 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