"Glen Choo via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > * die()-ing is necessary if we're trying to flip the default value of > discovery.bare. We'd expect many bare repo users to be broken, and it's > more helpful to fail loudly than to silently ignore the bare repo. > > But in the long term, long after we've flipped the default and users know > that they need to opt into bare repo discovery, would it be a better UX > to just silently ignore the bare repo? Would a middle-ground of giving a warning() message help? Can it be loud and annoying enough to knudge the users to adjust without breaking the functionality? The longer-term default should be "cwd is allowed, but we do not bother going up from object/04 subdirectory of a bare repository", not "bare repositories should not be usable at all without GIT_DIR". > + Add a config variable, `discovery.bare`, that tells Git whether or not > + it should work with the bare repository it has discovered i.e. Git will > + die() if it discovers a bare repository, but it is not allowed by Missing comma before "i.e." > ++discovery.bare:: > ++ Specifies what kinds of directories Git can recognize as a bare > ++ repository when looking for the repository (aka repository > + discovery). This has no effect if repository discovery is not > + performed e.g. the path to the repository is set via `--git-dir` > + (see linkgit:git[1]). > ++ > +This config setting is only respected when specified in a system or global > +config, not when it is specified in a repository config or via the command > ++line option `-c discovery.bare=<value>`. ;-) > +++ > ++The currently supported values are `always` (Git always recognizes bare > ++repositories) and `never` (Git never recognizes bare repositories). > ++This defaults to `always`, but this default is likely to change. > +++ > ++If your workflow does not rely on bare repositories, it is recommended that > ++you set this value to `never`. This makes repository discovery easier to > ++reason about and prevents certain types of security and non-security > ++problems, such as: Hopefully "git fetch" over ssh:// and file:/// would run the other side with GIT_DIR explicitly set? As long as this recommendation does not break these use cases, I think we are OK, but I do not yet find these "problems, such as..." so convincing.
