[RFC - draft #2] List of proposed future changes that are backward incompatible

Let's scrap the first thread and try again, this time a bit more careful wording, so that premature and unwanted discussions would not cloud out what really needs to happen in response to this request.

Here is a draft of a message I am preparing to send out around 1.6.2-rc2 is tagged to this mailing list, and mailing list of the projects that use git to track their changes, to announce possible future changes that may affect the users in a backward incompatible way, and solicit comments.

I am asking three things now from the readership:

 - For items that are already on the list, help improve the way the
   planned/proposed changes are explained.  Discussion on the desirability
   of the change itself is NOT WELCOME in this thread.  That is for the
   discussion that follows the final version of this document.

 - If a change, that was discussed on this list recently and saw general
   consensus that such a change is desirable, is missing from this
   document, please send in updates in a similar format as you see below.

 - If your favourite project that uses git is not listed in:

   http://git.or.cz/gitwiki/ProjectContacts

   or it does not have "Forwarder" field filled in, please add the project
   with an appropriate address for the message to be sent.

   Be careful NOT to list a mailing list address that non-subscribers
   cannot send messages to.  For such mailing lists, we need to find a
   subscribed volunteer to forward it.  If you are volunteering, great.

Thanks.

-- >8 -- cut here -- >8 --

To: git@vger.kernel.org
Subject: [RFC/WARNING] Proposed future changes that are backward incompatible

Here is a list of possible future changes to git that are backward incompatible that are under discussion on the git mailing list.

None of them will be in the upcoming 1.6.2 release, but some of them are likely to appear in future versions. If you think we should not introduce some of the listed changes, here is a chance to voice your opinions and make a convincing argument against them, so please do so. Many people complained about the removal of many git-foo commands from user's PATH, which was done in 1.6.0 based on user input, after it happened. You do not want to see such a mess happen again.

Thanks.

* git-push to update the checked out branch will be refused by default

  Make "git push" into a repository to update the branch that is checked
  out fail by default.  You can countermand this default by setting a
  configuration variable in the receiving repository.

  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007

* git-push to delete the current branch will be refused by default

  Make "git push $there :$killed" to delete the branch that is pointed at
  by its HEAD fail by default.  You can countermand this default by
  setting a configuration variable in the receiving repository.

  http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936

* git-send-email won't make deep threads by default

  Many people said that by default when sending more than 2 patches the
  threading git-send-email makes by default is hard to read, and they
  prefer the default be one cover letter and each patch as a direct
  follow-up to the cover letter.  You can countermand this by setting a
  configuration variable.

  http://article.gmane.org/gmane.comp.version-control.git/109790

* make core.quotepath=false the default

  By default, "git diff" output quotes bytes in pathnames with high bit
  set, primarily to avoid corruption during e-mail based transfer.  This
  however is inconvenient for human readers, and also makes some poorly
  written user scripts that do not unquote them fail.  Change the default
  so that they are not quoted (note that control characters such as HT are
  always quoted).  You can countermand this by setting a configuration
  variable.

  http://thread.gmane.org/gmane.comp.version-control.git/110033