Re: [PATCH 08/10] revert: Introduce HEAD, TODO files to persist state, plan

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