On 2009-05-29 09:40:59 +0100, Catalin Marinas wrote:
> 2009/5/29 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > On 2009-05-28 15:51:20 +0100, Catalin Marinas wrote:
> >
> > > 2009/5/28 Catalin Marinas <catalin.marinas@xxxxxxxxx>:
> > >
> > > What about this change to the original patch (it's faster to
> > > just return the sha1 refs than building the Commit objects):
> >
> > Creating Commit objects is really cheap---just look at the
> > constructor. I made them that way on purpose, so that we'd never
> > have to think twice about using Commit objects instead of passing
> > sha1s around.
>
> I was worried it may invoke git to get the CommitData.
Only if you try to access it---it's evaluated lazily.
> > Also, you said "set", and I agree---the return value of
> > get_mege_bases() should be a set. That's what it _is_,
> > conceptually, and it makes little sense to obscure that fact.
>
> If we return a set of commits, I suspect the Repository object
> guarantees that having the same sha1 value always returns the same
> Commit object
Yes, exactly. As long as you get all your Commit objects from the
Repository object like you're supposed to, there'll be at most one
Commit object for each sha1. In fact, the Commit objects don't have an
__eq__ method on purpose---straight object comparison already does
exactly what we want!
> and the code below is valid:
Yes, this is precisely what I meant.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html