On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov [off-list ref] wrote:

On Wed, Dec 02, 2015 at 08:13:41PM +0100, Nguyễn Thái Ngọc Duy wrote:

quoted

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.

quoted

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