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

[Jakub Narebski <jnareb@gmail.com>]

david@lang.hm writes:

> On Sun, 15 Feb 2009, Junio C Hamano wrote:
> 
> > 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.

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