Re: git-rev-list: proper lazy reachability

Linus, what do you think rev-list should do given HEADs from two forks, like this?

    JC          git-rev-list JC LT ????
     |
     |  LT
     |   |
      \ /
       |
       |
       |

The above is often the shape of my working repository. I pull from you, commit a handful on top of your then-HEAD, and when I am about ready to submit, I pull from you again to find your HEAD advanced somewhat.

For patch-form submission, I need a list of my commits since I forked from you. Also I tend to rebase to your head often, instead of merging inside my working repository (which makes later e-mail patch-form submission more work for me), so even when I am not immediately submitting the changes I have in my fork, I need that list to forward port my changes.

JIT currently uses this to get this list (as a workaround):

    git-rev-list JC $(merge-base JC LT)

I am wondering if this "since they forked" is usually what the user wants. If that is the case then it would be great if I did not have to do the "merge-base" part outside.

Current "proper lazy reachability" version, btw, does something very unexpected for my use pattern. If you have more than one commits between the fork point and LT HEAD in the above picture, everything from the beginning of time to JC is given, or something silly like that.