Re: Splitting a rev list into 2 sets

From: Francis Moreau <francis.moro@gmail.com>
Date: Jun 21, 2013, 07:15 UTC
Message-ID: <CAC9WiBieEG9zhiAqC+bwCAN8qutRr0L_-Fo19ORBqjecnBynhQ@mail.gmail.com>
In-Reply-To: <CALkWK0k_2jzQNBjLKZ4SDc9vqoZuQ7937dnO6Z_Ye4Ha+FNcag@mail.gmail.com>

Hi,

On Thu, Jun 20, 2013 at 3:47 PM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 12 quoted lines

> Francis Moreau wrote:
>> Basically I have an initial set (or can be several different sets)
>> expressed as a revision specification described by git-rev-list man
>> page. I just want to find the common set of commit which are part of
>> the initial sets *and* is reachable by master.
>
> That's just a generic list intersection between
>
>   [a, b, c] and [d, e, f]
>
> no?  [a, b, c] is a list you built up somehow, and [d, e, f] comes
> from $(git rev-list master), right?

yes.

>
> You could go about determining the revision walk boundaries and
> combine them to set up a revision walk to splice the master line, but
> what is the point of that?

Well, that seems to me a more elegant solution and I was curious about doing this with git-rev-list only if possible.

>  You'll only be painting yourself into a
> design-corner (you won't be able to do other kinds of filtering), and
> going around your head to touch your nose.

I think what Thomas proposed is fine.

>  You precisely want list
> intersection: so write an efficient list intersection in the language
> of your choice.  Why is it a poor man's solution?

Sorry my wording was poor. I just meant that it was the obvious solution that I don't find nice. But your implementation was good.

>  If anything, your
> convoluted rev-list solution will probably be more complicated,
> slower, and bug-ridden.

Slower ? why do you think Thomas' solution is slower than the obvious one ?

Thanks -- Francis