Le 23/08/2017 à 19:57, Junio C Hamano a écrit : > Nicolas Morey-Chaisemartin <nicolas@xxxxxxxxxxxxxxxxxxxxxx> writes: > >> Two questions: >> - Could this be a candidate for contrib/ ? >> - Would it be interesting to add the relevant code to sequencer.c >> so that all sequencer based commands could have a --status option > I actually think we would want a "git sequencer" command, which can > be fed an arbitrary instruction sheet created by a third-party and > told to "run" it. A new command $cmd that wants to rewrite history > (like "rebase -i", "cherry-pick A..B", etc. do) can only concentrate > on preparing the sequence of instructions and then internally invoke > "git sequencer run" until it gives the control back to the end user. > When the user tells $cmd to continue, it can relay that request to > "git sequencer continue" under the hood. > Once its use is established, it might be even possible to let users > run "git sequencer continue", bypassing frontends for individual > commands, e.g. "git cherry-pick --continue", etc., but I do not know > if that is generally a good idea or not. In any case, having such a > front-end will help third-party scripts that want to build a custom > workflow using the sequecing machinery we have. > > And in such a world, we would need "git sequencer status" command > to give us where in a larger sequence of instrutions we are. > > So I tend to think this should be part of the core, not contrib/, > and should become part of a new command "git sequencer". I like your idea. I'm not sure I have the bandwidth to do this (by myself at least). If someone (hopefully more familiar with the sequencer code than me) wants to work on this, I'd gladly help. Nicolas
