Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. Ah, that is very helpful. Thanks. It's pretty clear that I misunderstood what you meant by "giving a warning() message" - the warning() is there to prepare users in advance of the change; we don't actually want the warning() in the long term. For something as disruptive as discovering bare repos, having all of (1), (2) and (3) sounds appropriate. >>> 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. Let me clarify in case this wasn't received the way I intended. Earlier in the thread, you mentioned: The longer-term default should be "cwd is allowed, but we do not bother going up from object/04 subdirectory of a bare repository", [...] which I took to mean "Junio thinks that, by default, Git should stop walking up to find a bare repo, and thinks this is better because of rationale X.", and not, "Junio does not think that the default needs to change, but is just suggesting a better default than Glen's". If it is the former, then there is obviously some thought process here that is worth sharing. If it the latter, then I'm in favor of taking Stolee's suggestion to drop "cwd", since nobody else finds it useful enough. (I like the 'simplification' story, but not enough to push "cwd" through, especially since it does quite little security-wise.) >> 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. Fair. I'll mull over this.
