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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html