On Fri, 2011-04-01 at 13:01 +0200, Dirk Wallenstein wrote: > On Wed, Mar 30, 2011 at 06:25:12PM -0300, Guilherme Salgado wrote: > > On Wed, 2011-03-30 at 12:10 +0800, Jeremy Kerr wrote: [...] > > +def ensure_source_checkout_for_project(project): > > + forest = '/home/salgado/src' # This is where we store the trees we > > checkout > > + root = os.path.join(forest, project.linkname) > > + if not os.path.exists(root): > > + repo = Repo.init(root, mkdir=True) > > + else: > > + repo = Repo(root) > > + > > + transport, path = get_transport_and_path(project.source_tree) > > + refs = transport.fetch(path, repo) > > + # XXX: Is this the appropriate thing to do? will there always be a > > master > > + # branch? > > + repo.refs['refs/heads/master'] = refs['HEAD'] > > + return repo > > + > > + > > +def get_hashes_for_commits(repo, stop_at): > > + # We don't care about the first commit, but if needed it should be > > + # possible to diff it against an empty tree and yield its hash as well. > > + commit = repo['HEAD'] > > + > > + while len(commit.parents) > 0: > > + commit_id = commit.id > > + if commit_id == stop_at: > > + break > > + > > + parent = repo[commit.parents[0]] > > What about possible other parents? I would say every merged branch has > to be inspected until the merge-base of the immediate predecessors --
That's one of the reasons that led me to run git as a subprocess instead of using python-dulwich. In a followup to this thread I sent a new version of this patch which uses just git. > maybe recursion works here. I forgot to mention Git-Python in the other > mail. It has a wrapper to execute git commands with python syntax. > That can facilitate such things. > > https://github.com/gitpython-developers/GitPython Oh, cool, I'll have a look at that. Cheers, -- Guilherme Salgado <https://launchpad.net/~salgado>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
