From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Thu, 02 Jun 2011 12:53:03 GMT
Subject: Re: [PATCH 08/10] revert: Introduce HEAD, TODO files to persist state, plan
Message-ID: <BANLkTinc=9aW_y6s-Zb578QsMawnxFD55Q@mail.gmail.com>
In-Reply-To: <20110601193126.GC9730@elie>

Hi Jonathan,

Jonathan Nieder writes:
> . If no, the "todo list" needs to be fully resolved to start out, and
>  then the cherry-pick loop can just walk through it.  In git API
>  terms, that means first populating the commit_list (for example
>  using a loop that gets revisions and inserts them at the end of a
>  commit_list, or by preparing the revision walk with "limited" flag
>  set), then walking through it with commit_list APIs.

Thanks. I picked this approach :)

On a slightly unrelated note, I just found out that the persist_todo
can't be called twice due to a lockfile API limitation* -- the
atexit(3) cleanup handler is supposed to have a linked list of
lockfiles to clean up. When one lockfile is used twice, it becomes a
circularly linked list, and the entire program hangs at exit time
since traversing a circularly linked list is never-ending. Couple of
comments:
1. By reading the lockfile implementation, I understand why this
happens -- can't it be implemented differently to remove this
limitation? If not, shouldn't this limitation be documented somewhere?
2. What can I do? It'll be inelegant to use the lockfile API while
persisting the first time, but not the second time -- is there any way
out of this?

Thanks again.

* You brought this up during one of our IRC conversations, but I
didn't understand it then. I do now.

-- Ram