Jonathan Nieder wrote:
> For the sake of new and forgetful readers: what is that objective?
The objective is to build a generalized sequencer, of which "git
revert" and "git cherry-pick" are two special cases. We can later
extend it to encompass more builtins and other commands. Why? In
general, we want uniform semantics to continue, skip, and abort any
operation that requires user-intervention (example: a conflict that
needs to be resolved before proceeding). A lot of this work is
inspired by the way "rebase -i" works: it presents the user an
instruction sheet with a sequence of actions to perform. Example
future use cases:
$ git cherry-pick moo..foo
[conflict]
$ edit problematicfile
$ git add problematicfile
$ git continue
[finishes successfully]
$ git revert moo..foo
[conflict]
$ edit problematicfile
$ git add problematicfile
$ git continue
[finishes successfully]
In these examples, the instruction sheet is uniformly filled with
"pick" or "revert" actions, which is not very interesting. When we
get an interface to allow easy editing of the instruction sheet and
encompass more builtins, more interesting sequences of operations will
be possible like:
pick rr/revert-cherry-pick^2~34
revert master@{12}
merge next
am /tmp/jrn.patch
Thanks.
-- 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