On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov <max@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html