On 03/02/2014 04:55 PM, Matthieu Moy wrote: > Eric Sunshine <sunsh...@sunshineco.com> writes: > >> On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine <sunsh...@sunshineco.com> >> wrote: >>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy <pclo...@gmail.com> >>> wrote: >>>> This is "rev-list style", where people can do "git rev-list -3" in >>>> addition to "git rev-list HEAD~3". A lot of commands are driven by the >>>> revision machinery and also accept this form. This addition to rebase >>>> is just for convenience. >>> >>> I'm seeing some pretty strange results with this. If I use -1, -2, or >>> -3 then it rebases the expected commits, however, -4 gives me 9 >>> commits, and -5 rebases 35 commits. Am I misunderstanding how this >>> works? >> >> Nevermind. I wasn't paying attention to the fact that I was attempting >> to rebase merges. > > Your remark is actually interesting. Most (all?) Git commands taking > -<n> as parameters act on n commits, regardless of merges. > > So, this commit creates an inconsistency between e.g. "git log -3" (show > last 3 commits) and "git rebase -3" (rebase up to HEAD~3, but there may > be more commits in case there are merges). > > I don't have a better proposal, but at least the inconsistancy should be > documented (e.g. "note that this is different from what other commands > like 'git log' do when used with a -<number> option since ..." in the > manpage).
This might be a reason that "-NUM" is a bad idea. Or perhaps "-NUM" should fail with an error message if any of the last NUM commits are merges. In that restricted scenario (which probably accounts for 99% of rebases), "-NUM" is equivalent to "HEAD~NUM". Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
