On Wed, Mar 18, 2015 at 3:04 PM, Ephrim Khong <dr.kh...@gmail.com> wrote: > Without having looked into this and nd/multiple-work-trees, but with "make > multiple checkouts aware of each other" in mind: Could this mechanism be > re-used to make alternates aware of each other, to mitigate the dangers of > having git gc on an alternate remove objects that are used by a > referencing repository?
If we can turn on ref namespace and make $GIT_DIR/config and hooks per worktree, I think it may have a chance of replacing alternate object mechanism entirely: one object database, one ref database (but refs of each worktree is namespaced so no conflicts), multiple worktrees, multiple config files, multiple hooks. Because some config keys affect object database, having multiple/conflicting config keys imply that this worktree may change object database in a way trhat impacts performance (not correctness) of another worktree. Later on when we have multiple ref backends, if config keys can change ref backend behavior (or even choose the backend), we may run into other problems. This problem might go away if we define that those "global" config keys can't be per-worktree.. In short, I am good at confusing people. -- 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
