Show 6 quoted lines
> . 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
Ramkumar Ramachandra <artagnon@gmail.com>