david@xxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
