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.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html