Glen Choo <chooglen@xxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> "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?
>
> Personally, when my tool changes its behavior, I would strongly prefer
> it to die than to "change behavior + warn". I'd feel more comfortable
> knowing that the tool did nothing as opposed to doing the wrong thing
> and only being informed after the fact. Also, I sometimes ignore
> warnings ;)
Heh, personally I would try very hard not to change the behaviour
without explicitly asked by the users with configuration or command
line option. Flipping the default has traditionally been done in
two or three phases.
(1) We start by giving a loud and annoying warning to those who
haven't configured and tell them the default *will* change, how
to keep the current behaviour forever, and how to live in the
future by adopting the future default early.
(2) After a while, we flip the default. Those who haven't
configured are given a notice that the default has changed, how
to keep the old behaviour forever, and how to explicitly choose
the same value as the default to squelch the notice.
(3) After yet another while, we stop giving the notice. If we
omitted (2), here is where we flip the default.
Strictly speaking, we can have (1) in one release and then could
directly jump to (3), but some distros may skip the releases that
has (1), and (2) is an attempt to help users of such distros.
>> Hopefully "git fetch" over ssh:// and file:/// would run the other
>> side with GIT_DIR explicitly set?
>
> Ah, I'll check this and get back to you.
>
>> I do not yet
>> find these "problems, such as..." so convincing.
>
> What would be a convincing rationale to you? I'll capture that here.
That is a wrong question. You are the one pushing for castrating
the bare repositories.
> I'm assuming that you already have such an rationale in mind when you
> say that the longer-term default is that "we respect bare repositories
> only if they are the cwd.". I'm also assuming that this rationale is
> something other than embedded bare repos, because "cwd-only" does not
> protect against that.
No, I do not have such a "different" rationale to justify the change
proposed in this patch. I was saying that the claim "embedded bare
repos are risky", backed by your two examples, did not sound all
that serious a problem. Presented with a more serious brekage
scenario, it may make the description more convincing.
Thanks.
