Quoting Johannes Schindelin <Johannes.Schindelin@xxxxxx>:
> You cannot just cater for one workflow and fsck the other workflows over.
>
> You'll have to devise a method that helps the workflow you are interested
> in, but leaves the others alone.
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?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
