Hi,
Dave Olszewski wrote:
> It's trivial for someone to update build software from "git push remote
> tag" to "git push remote +tag" or "git push -f remote tag", but I can
> understand your objection.
Right. The thing to prevent is unhappy surprises: it is best if
users upgrading get a chance to update their scripts before it matters.
> It seems unlikely that many people are ever going to "flip on" this
> feature; either they won't know about it (and for them, it should be
> on), or they'll have a reason to move a tag, and want it off.
This is why a switch of some kind is useful: after reading the release
notes, a user can flip the switch for a glimpse of the future, forsee
the upcoming disaster, and fix everything up before it really matters.
After the default changes, the switch has the opposite purpose: users
who were not prepared can use it to turn back time and avoid having
to change their code.
So the deprecation process for unwanted features tends to look like
this:
1. complain about use of the feature, with an option to suppress
the warnings. or: loudly proclaim that the feature is going
away in release notes
2. add an option to disable the feature, to help people transition
3. change the default to true
4. remove the option
Step 1 is the most important one imho. See
Documentation/RelNotes-1.6.6.txt for an example.
I don't think we've ever reached step 4, but we should try it some
time.
Hope that helps,
Jonathan
--
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