Hi Jonathan and Sverre, Jonathan Nieder writes: > Wait, so what is the actual impact of this patch? > > As far as I can tell, it is to introduce a remove_sequencer_state() > function whose eventual purpose would be to remove the .git/sequencer > directory used by "git cherry-pick" to record its progress. Paraphrased, > the function does this: > > rm -fr "$GIT_DIR/sequencer-old" > mv "$GIT_DIR/sequencer" "$GIT_DIR/sequencer-old" > > This way, a person has one level of "undo" possible, assuming git > commands and scripts use the function carefully enough not to call it > twice. > > Is the "undo" feature advertised anywhere? Should this function write > a message to stderr to inform the operator about how to get back the > precious cherry-pick state? I don't think we should advertise it on stdout or stderr. I think of a safeguard that only very few people will use. Ofcourse, documenting it somewhere like Documentation/technical will make sense once we have something usable. > If I were doing it, I'd squash this with the patch that introduces > "git cherry-pick --quit", to give an example of how the new function is > meant to be used (and tests!). I would have done that too, except that the "reset: Make hard reset remove the sequencer state" patch depends on this. So, I don't think it's fair to squash it into either patch. I can definitely write a better commit message though (wait for the next iteration to see it). Sverre Rabbelier writes: > I think we can learn from hg here and just use a datetime stamp. So > instead of moving to sequencer-old move to sequencer-20110713-141022 > or such. That way there's as many undo as you need. That's a great example in general, but I'm wondering if it would really be useful for this particular usecase. Are sequencer states so valuable that we want to allow so many levels of undo? -- 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