Francis Moreau <francis.m...@gmail.com> writes:
> On Thu, Jun 20, 2013 at 3:20 PM, Thomas Rast <tr...@inf.ethz.ch> wrote:
>> positive=$(git rev-parse "$@" | grep -v '^\^')
>> negative=$(git rev-parse "$@" | grep '^\^')
>> boundary=$(git rev-list --boundary $positive ^master | sed -n 's/^-//p')
>> # the intersection is
>> git rev-list $boundary $negative
>
> I think there's a minor issue here, when boundary is empty. Please
> correct me if I'm wrong but I think it can only happen if positive is
> simply master or a subset of master. In that case I think the solution
> is just make boundary equal to positive:
>
> # the intersection is
> git rev-list ${boundary:-$positive} $negative
>
> Now I'm going to see if that solution is faster than the initial one.
Jan "jast" Krüger pointed out on #git that
git log $(git merge-base --all A B)
is exactly the set of commits reachable from both A and B; so there's
your intersection operator :-)
So it would seem that a much simpler approach is
git rev-list $(git merge-base --all master $positive) --not $negative
avoiding the boundary handling and special-case. It relies on the
(weird?) property that $(git merge-base --all A B1 B2 ...) shows the
merge bases of A with a hypothetical merge of B1, B2, ..., which is just
what you need here.
--
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
