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

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 15, 2009, 23:01 UTC
Message-ID: <m3fxifticm.fsf@localhost.localdomain>
In-Reply-To: <alpine.DEB.1.10.0902151544510.14911@asgard.lang.hm>

david@lang.hm writes:

Show 19 quoted lines

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

Show 12 quoted lines

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

Show 8 quoted lines

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