Thanks for the thoughtful replies, everyone. I'm still catching up with
the discussion but I thought I'd share a suggestion/observation from
a colleague (cc-ed, thanks!) who was following the discussion
separately.
Glen Choo <chooglen@xxxxxxxxxx> writes:
> = What can we do about it?
>
> Each subsection is an alternative and an analysis (+/- are pros/cons).
>
> == 1. Prevent users from checking out bare repos
> ...
> == 2. Detect and reject bare repos using `git fsck` and `transfer.fsckObjects`.
> ...
> == 3. Detect that we are in an embedded bare repo and ignore the embedded bare
> repository in favor of the containing repo.
> ...
> == 4. Educate users about this risk without making code changes.
Martin observed that, viability aside, there's another approach that I
haven't discussed:
== 5 Disable bare repo discovery
We could introduce a config value that disables bare repo discovery
altogether. This would only disable _discovery_; a user can still use
the bare repo by specifying the gitdir (e.g. via `--git-dir=.` or
GIT_DIR).
+ Extremely robust (for the majority of users who don't need bare
repos at least).
+ Easy to understand.
- We need to read config _before_ discovering the gitdir; although Git
_can_ do this (e.g. via read_early_config()), I don't think there is
precedent for doing this during repository setup.
- Making this behavior opt-out would break every bare repo user
(they'd need to either start passing --git-dir or change their
config).
- Making this behavior opt-in won't help the users who need it the
most.
I'm not sure if specifically "disable bare repo discovery for all users
by default" is viable, but the line of thinking seems like it might
yield some good ideas.
Thoughts?
