Re: Shelving and Checkpointing support log messages

Julian Foad wrote on Thu, 24 Aug 2017 19:46 +0100:
> I think we will encounter two distinct styles of usage:
>
> * "just put whatever I have aside, I haven't time to think about it
> now, I'll come back to it later" -- no description or just a very brief
> hint, and perhaps not even a name;
>
> * "this is a patch I have prepared" with a carefully written log message.
>

Agreed.

> One rough edge is that "unshelving" a patch or finishing/squashing a
> checkpoint series simply discards the log message(s). I welcome your
> thoughts.

I doubt anyone would store a verbose long message on a shelved
patch if applying the patch would discard the log message. People would
grow the habit of storing the log message out of band.

Conversely, to enable the "long log message" use-case, there should be an easy
"upgrade path" for the shelf's log message to become a commit log message;
optionally with editing first.

Example workflow:

1. There exists a shelf with a verbose log message
2. Unshelve that patch
3. 'make check'
4. 'svn commit'

In this workflow, it would be nice for $EDITOR to be pre-filled with the
shelf's log message.

The catch is, what happens if the patch is reverted (with 'svn revert'
or with an equivalent '/usr/bin/patch -R') before step 4. In that case,
the user wouldn't want the shelf's message to be presupplied.

The problem is that between #2 and #4 we have hidden state: step #4
doesn't know whether it's committing the patch that had been
unshelved, or something else --- and if we have to guess, we'll
sometimes guess wrongly.

(That's all I have for now...)

Cheers,

Daniel
Received on 2017-08-25 00:45:31 CEST