Re: [RFC - draft] List of proposed future changes that are backward incompatible

david@lang.hm writes:

On Sun, 15 Feb 2009, Junio C Hamano wrote:

quoted

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.

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

If I understand this one, it will cause grief for quite a few people.

I have a public repository that I push to and then have a trigger that
checks out the current version, compiles it, publishes the compiled
version, sends an announcement, etc

if I am understanding the purpose of this change, you would prohibit
the update from taking place.

No, you just have to configure it to enable it.  In the meantime
(before the change) you would get warnings unless you configure it.

quoted

* 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.

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

I have mixed feelings about this one, if some messages get delayed in
transit the deep threads still keeps them in order, while the 2-layer
option doesn't.

That is whay you should use --numbered (and I think it should be
default for --no-chain-reply-to), using [PATCH m/n] prefix.

Note that usually you would have problems if patch arrive out of
order, unless your enail client / news reader is able to rethread.

that being said, I don't think it's that significant to change the
default.

It is much, much nicer when there is discussion on the patches in
patch series to have 'shallow' threading (cover letter + patches
numbered being reply to cover letter).

Unless you don't get review of patches, then deep threading might look
as nice...

one thing that would help new users is if there was a way to create a
git config file that explicitly listed all the defaults. either as a
sample config, or to expand the existing config file with all the
defaults listed, but commented out.

I find that having such a config file helps me find config options I
never thought to look for.

That is a very good idea... if next to impossible now, I think, as
there is (I guess) no single place that stores default values.  But
perhaps I am mistaken.

-- 
Jakub Narebski
Poland
ShadeHawk on #git