On Sun, 10 Apr 2011, Jonathan Nieder wrote: > > 3. From the format of the TODO and DONE files, one more thing should > > be clear- I'm trying to stick to a slight variation of the 'rebase -i' > > format. This part will go into the sequencer. Then I'll use a > > cherry-pick specific file to keep the command-line options. Yes, I'm > > trying to work on Daniel's idea [3] from the very start. Is this a > > good idea? > > This is still bouncing in my head. I think I like it --- is the idea > that some day you could put commands like > > am topic.mbox > > in your insn sheet, or do nested rebases with a --force-nested option? > That does sound useful. How would one request "skip to the next > operation in the outer rebase" on the command line? This is starting > to feel like a debugger. The most basic idea is that, in the case of a rebase where a patch fails to apply, there are actually two levels of operation that have to be deferred until after the human intervention: making the commit where the pick failed, and applying further patches. If there are going to be multiple higher-level operations (e.g., rebase and rebase -i), they should be able to share the completion of the pick operation, and a basic "git cherry-pick <sha1>" ought to be able to share it, too, so you can finish that up without having to remember what the command is. People should be able to implement custom higher-level operations (e.g., "cherry-pick all the commits attached to bugs in bugzilla that block the release tracker" or something), they should be able to rely on library code that knows how to finish the conflicted cherry-pick. (Another interesting example might be "reconstruct the linux-next tree", which is a series of merges, and which should have --continue share the post-intervention code from the single merge process before going on to do the custom higher-level thing.) My feeling is that "--skip" is actually "abort the pick, but continue the rebase". I suppose there could be more than two levels, and people could want to skip a higher-level chunk, but that's something to get to when someone actually wants it; we've obviously already got the two-level situation now, so we can implement that. -Daniel *This .sig left intentionally blank* -- 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