Hi, Antonio Ospite wrote: > vcsh[1] uses bare git repositories and detached work-trees to manage > *distinct* sets of configuration files directly into $HOME. Cool! I like the tooling you're creating for this, though keep in mind that Git has some weaknesses as a tool for deployment. In particular, keep in mind that when git updates a file, there is a period of time while it is missing from the filesystem, which can be problematic for dotfiles. [...] > However when multiple repositories take turns using the same directory > as their work-tree, and more than one of them want to use submodules, > there could still be conflicts about the '.gitmodules' file because git > hardcodes this path. > > For comparison, in case of '.gitignore' a similar conflict might arise, > but git has alternative ways to specify exclude files, so vcsh solves > this by setting core.excludesFile for each repository and track ignored > files somewhere else (in ~/.gitignore.d/$VCSH_REPO_NAME). For reference: core.excludesFile Specifies the pathname to the file that contains patterns to describe paths that are not meant to be tracked, in addition to .gitignore (per-directory) and .git/info/exclude. Defaults to $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead. See gitignore(5). Using this as a substitute for <worktree>/.gitignore is a bit of a hack. It happens to work, though, so reading on. :) [...] > So this series proposes a mechanism to set an alternative path for the > submodules configuration file (from now on "gitmodules file"). I am nervous about this. I wonder if there is another way to accomplish the goal. One possibility would be to handle the case where .gitmodules is excluded by a sparse checkout specification and use .gitmodules from the index in that case. Would that work for you? Thanks, Jonathan
