Thread (11 messages) flat view 11 messages, 3 authors, 2016-06-15

Re: [RFC][StGit PATCH] Add support for merge-friendly branches

From: Karl Hasselström <hidden>
Date: 2016-06-15 22:46:52

On 2009-05-29 09:40:59 +0100, Catalin Marinas wrote:
2009/5/29 Karl Hasselström [off-list ref]:
quoted
On 2009-05-28 15:51:20 +0100, Catalin Marinas wrote:
quoted
2009/5/28 Catalin Marinas [off-list ref]:

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.
quoted
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@treskal.com
      www.treskal.com/kalle
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help