On Mon, 11 Apr 2011, Christian Couder 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? > > I think that the TODO and DONE file format will need at one point to include > options and it is simpler if this change is done early. Using a cherry-pick > specific file to keep the options is not very generic for a sequencer that could > be used for many things. My idea is that cherry-pick (or merge, or whatever) would have its own state to store what it was trying to do when it got a conflict. This is to enable the cherry-pick (etc) to complete without needing to know anything about what called it. The sequencer's information would keep track of what was left to do, what was already complete, and how to abort the whole sequence. It would be nice to get the following commands to work: $ git cherry-pick <sha1> Automatic cherry-pick failed. After resolving the conflicts, mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and run 'git continue' $ (resolve conflicts) $ git continue Finished one cherry-pick. [master sha1b] Subject 2 files changes, 2 insertions(+) And, of course, if this happened as a step in a rebase, the rebase would continue after the cherry-pick finished. But it's annoying that, in order to finish a conflicted "git cherry-pick <branch>", you currently need to go back and find the instruction that says to commit it yourself, with the option "-c <sha1>" to retain authorship and message. And if you want to abort it, you need to remember "git reset --hard HEAD" (and maybe you also want "git rerere clear"). That's what cherry-pick should be keeping its own state for. This is also parallel to how "merge" works, with its information kept in private state files, including some things like the list of files that had conflicts which isn't trivial to reproduce after the user has resolved them. -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