On 11/28/18 3:21 AM, brian m. carlson wrote: Thanks for the elaboration, Brian - good to get things down to a practical, real-world level. > [...] > > I point this out to underscore how fundamental this change is. People > overwhelmingly do not read the release notes, so expecting people to > realize that a change has been made, especially when many people only > upgrade Git because of a security issue, may result in unexpected > consequences. This is one of the more important things of software engineering. _Don't mix security fixes with breaking changes_. They are very different things and like you say, we can't really expect people to real release notes for every little incremental release we do. That's an important part of the SemVer guarantee: a minor version bump/patch level increase means "bug fix" or "added functionality in a backwards-compatible way". So: no changing of default behavior or semantics, but adding a new behavior which is opt-in is perfectly fine. > Just because we don't think of this use of Git as normal or desirable > doesn't mean people don't do it and don't expect it to keep working. In other words, we need to be "bug-by-bug" compatible with previous versions. :-) What some people would consider a bug, others would consider a feature. > I think any change we make here has to be opt-in, at least until Git > 3.0. A config knob would probably be the right way to go. Agree. It's less than optimal but I think it's something that we all could live with. Deciding to switching the default (or not) is then rightfully postponed to a later time, and we can revisit the pros and cons then. The important thing now is to get the functionality implemented in a good way, tested and eventually merged. -- Per Lundberg
