Re: [PATCH 10/17] sequencer: Announce sequencer state location

[Ramkumar Ramachandra <artagnon@gmail.com>]

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