Re: [PATCH 11/10] allow forcing index v2 and 64-bit offset treshold

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicolas Pitre <nico@xxxxxxx> writes:

>> They are _not_ even in 'pu'.  I am talking about things that
>> have been cooking.
>
> Remember that positive comments are by default much less verbose than 
> negative ones. In other words, no news is probably good news.

No news means one or more of the following:

 - Immediately before 1.5.1, people were asked to test 'master'
   rigorously, and they did, and they are still on 'master'.
   Nobody noticed breakages in 'next'.

 - Some people use 'next' but the new features, fixes or
   enhancements the topics introduce are totally irrelevant to
   how they use git, so problems are not noticed.  This would
   indicate that some of the topics may not even deserve to
   be in 'next'.

 - Most people are generally 'wait and see' and even when warned
   that some new features cooking in 'next' may change the user
   experience (even in good ways), they do not try to see if the
   change may adversely affect them to voice their objection
   early, to catch the changes they do not like before they
   graduate to 'master', and then complain.  This would indicate
   that it is futile to have 'next' as a holding area.  It would
   be more effective to push out unproven stuff on 'master' to
   make sure people complain.

None of the above does not sound a good news at all to me.

>> >> > ddiff --git a/t/Makefile b/t/Makefile
>> >> 
>> >> ???
>
> $ touch t/Makefile
> $ git diff

This still does not give me doubled d in diff.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]