Bug with rev-list --reverse?
Hi, If I do these: % 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? Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug with rev-list --reverse?
On Thu, Apr 18, 2013 at 05:17:14AM -0500, Felipe Contreras wrote: If I do these: % 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? I expect to get the same output. This is probably because I consider --reverse to be an output filter. So I expect to show the commits v1.8.1.5^..v1.8.1.6 -1 which selects a single commit and then show that in reverse order. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug with rev-list --reverse?
Felipe Contreras: % 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. -- \\// Peter - http://www.softwolves.pp.se/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug with rev-list --reverse?
On Thu, Apr 18, 2013 at 5:26 AM, John Keeping j...@keeping.me.uk wrote: On Thu, Apr 18, 2013 at 05:17:14AM -0500, Felipe Contreras wrote: If I do these: % 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? I expect to get the same output. This is probably because I consider --reverse to be an output filter. So I expect to show the commits v1.8.1.5^..v1.8.1.6 -1 which selects a single commit and then show that in reverse order. How about this: % git log --oneline --reverse --max-count=1 v1.8.1.5^..v1.8.1.6 In this case --max-count is acting as start from the first commit before the tip, not as output a maximum of one commit. Given that the name is max-count, I expect it to be the later. And if max-count doesn't select a maximum of n commits, then what does? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug with rev-list --reverse?
On Thu, Apr 18, 2013 at 5:47 AM, Peter Krefting pe...@softwolves.pp.se 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. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug with rev-list --reverse?
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 18, 2013 at 5:47 AM, Peter Krefting pe...@softwolves.pp.se
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug with rev-list --reverse?
Thomas Rast tr...@inf.ethz.ch writes: 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). Please don't. The fact that reverse then count mode may be useful does not mean count then show in reverse mode does not have any use. git log --oneline --reverse -20 is a very valid way to ask what did I do recently and get you did this, that and then... in that order. Adding a new option can be done anytime without any complex transition plan. You may want to introduce a --show-in-reverse synonym to the current --reverse when you add the new mode of reversing (--reverse-before-count?) so that eventually we won't have to ask which kind of reverse an unadorned --reverse option mean? by deprecating a plain --reverse, though. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
