On Tue, Sep 25, 2018 at 11:26 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > Warning: devil's advocate mode on. Oh good. I need to a good dose of sanity anyway. > Done in either way, this will confuse the users. What is the reason > why people are led to think it is a good idea to use multiple > worktrees, even when they need different settings? What do they > want out of "multiple worktrees linked to a single repository" as > opposed to just a simple "as many clones as necessary"? Reduced > disk footprint? I believe the main selling point of multiple worktrees is sharing refs. You could easily avoid expensive clones with --local, but synchronizing between different clones is not very convenient. Other than that, different worktrees tend to behave like separate clones. This leaves a gray area where other things should be shared or not. I think the preference (or default mode) is still _not_ shared (*). Sharing more things (besides refs and object database) is just a new opportunity popping up when we implement multiple worktrees. Since multiple worktrees (or clones before its time) are grouped together, sometimes you would like to share common configuration. We could sort of achieve this already with includeIf but again not as convenient. (*) real life is not that simple. Since refs are shared, including _remotes_ refs, so configuration related to remotes should also be shared, or it will be a maintenance nightmare. Which is why $GIT_DIR/config so far has been shared besides the two exceptions that are core.bare and core.worktree. And I really like to get rid of these exceptions. > Is there a better way to achieve that without the > downside of multiple worktrees (e.g. configuration need to be > uniform)? Is there a better way to achieve sharing refs between clones? I gave it a minute but couldn't come up with a good answer :( > > (*) "git config --worktree" points back to "config" file when this > > extension is not present so that it works in any setup. > > Shouldn't it barf and error out instead? The intention is a uniform interface/api that works with both single and multiple worktrees configurations. Otherwise in your scripts you would need to write "if single worktree, do this, else do that". If "git config --worktree" works with both, the existing scripts can be audited and updated just a bit, adding "--worktree" where the config should not be shared, and we're done. > A user who hasn't enabled > the extension uses --worktree option and misled to believe that the > setting affects only a single worktree, even though the change is > made globally---that does not sound like a great end-user experience. I was talking about a single worktree. But I think here you meant the user has multiple worktrees, but the extension is not enabled. I'm probably not clear in the commit message, but "git config" can detect that the extension has not been enabled, automatically enable it (and move core.bare and core.worktree (if present) to the main worktree's private config), so "git config --worktree" will never share the change. But perhaps the user should be made aware of this situation and asked to explicitly enable the extension instead? It's certainly a more conservative approach. -- Duy
