Re: Bug with rev-list --reverse?

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

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:

> On Thu, Apr 18, 2013 at 5:47 AM, Peter Krefting <peter@xxxxxxxxxxxxxxxx> wrote:
>
>>> % git log --oneline -1 v1.8.1.5^..v1.8.1.6
>>> % git log --oneline --reverse -1 v1.8.1.5^..v1.8.1.6
>>>
>>> I expect to get a different output, and not both showing v1.8.1.6.
>>> Wouldn't you agree?
>>
>>
>>  Quoting the manual page:
>>
>>  Commit Limiting
>>    Besides specifying a range of commits that should be listed using the
>> special notations explained in the description, additional commit limiting
>> may be applied. Note that they are applied before commit ordering and
>> formatting options, such as --reverse.
>>
>> Given that, I would expect the output to be the same.
>
> If expectations were based on documentation, all one has to do is
> document bugs, and there would be no bugs anymore :)
>
> Code can be changed to fit more appropriately user expectations (which
> are independent of documentation), and the documentation updated
> accordingly.

It's been this way forever, and applies to rev-list where we can't just
break how options work (for fear of breaking scripts).

You could come up with a patch series that first starts emitting
warnings whenever the user asks for behavior that will change, and later
flips the default and removes the warning (the latter would be merged
for 2.0 or so).

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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]