Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"

Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:

I think you'd want to repeat that to yourself when you propose to switch the default for denyCurrentcurrentBranch config to "true" too hastily the next time?

I don't think your patch matches the tradition of how defaults are changed in git project. You don't introduce a large change just after the maintainer hints about going into a freeze for 1.X.Y release when Y isn't zero.

I assume that everybody, including the maintainer who is too heavyweight and has too much inertia to accept too sudden a change of the course, wants to eventually make the default to deny pushing to the current branch. But I think such a change should come at 1.7.0 release at the earliest, and a constructive thing to do is to put in a patch to 1.6.2 that helps the users with the eventual transition.

How about doing these before the 1.7.0 release?

 1. Add some code to git-clone to set the config to "deny" if it is
    not a bare repository. The reason I think this makes sense is
    because the reason why old-timers want to push into the current
    branch is because they are used to the old layout that doesn't use
    separate remotes. If they use today's git-clone and still want to
    use the old layout, they need to update the config file in the new
    clone anyway. The "deny" is just another thing for them to fix at
    that point.

    I suspect that Junio will not like this in 1.6.2 because it is an
    unannounced and unplanned change in behavior, but I think it is a
    reasonable preparatory step, probably in 1.6.3, before you change
    the default to deny in release 1.7.0.

 2. Reword the warning message as Junio suggested in his response. I
    don't know the details of the code very well, but I think you can
    tell a repository that doesn't have the config at all from a
    repository that has the config set to "warn", and you can use
    "annoyingly long" (in Junio's words) message to force the user set
    the config to a desired value only when pushing into the former
    kind, and say that the default will change to deny in release
    1.7.0. When pushing into the latter, the warning message can be
    shorter (probably you can say "warning: updating the current
    branch in a non-bare repository" and nothing else).

 3. Reword the error message as you proposed to say "error: won't
    update the current branch in a non-bare repository", without
    saying anything else. You want to eventually change the default to
    deny, and there is no point to teach how to allow it to people who
    set the config to deny themselves, nor to new people who created
    their repository with updated git-clone.

    I think this makes sense to do in 1.6.2 release, because the only
    people who will see this message will be the people who set the
    config to deny themselves, especially if you postpone the change
    to git-clone for the upcoming release.

What do people think?