John Keeping wrote: > How is it only useful for builtin commands? By that logic everything > belongs in builtin/ because it's all only used by builtin commands (I > realise that is what you're arguing towards). sequencer.c is merely a common API for builtins to invoke "continuations": i.e. stop the program persisting enough state to let to user continue, allow the user to do whatever conflict resolutions using whatever tools, allow the user to continue the original operation. sequencer.c provides a uniform UI (--continue|--skip|--abort), and a uniform way to persist state (.git/sequencer/todo). It mainly abstracts out the boring details of reading/writing the todo lines. Currently, sequencer.c has no callers other than those in builtin/revert.c. In its current shape, it's incapable of being used by anything else: while an external ruby script (possibly a rebase implementation) could call into the sequencer to persist state, I don't think it is going to happen anytime soon. We might get a proper public api sequencer sometime in the distant future, but don't confuse that with the current shape of sequencer.c. > But we make a distinction between things that are specific to one > command (especially argument parsing and user interaction) and more > generally useful features. Copying notes around in the notes tree is > generally useful so why shouldn't it be in notes.c with the other note > manipulation functions? The current API may not be completely suitable > but that doesn't mean that it cannot be extracted into notes.c. In > fact, other than the commit message saying "Notes added by 'git notes > copy'" I don't see what's wrong with the current functions being > extracted as-is. Sure, notes could have a better public api and so could a lot of other things: worktree operations like reset and checkout come to mind. The problem is that we seem to be at some frozen in some sort of stalemate, and some reorganization is definitely required. What would you suggest? -- 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