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