Re: [PATCH v2 23/23] rebase -i: enable options --signoff, --reset-author for pick, reword

[Michael Haggerty <mhagger@alum.mit.edu>]

On 08/07/2014 01:59 AM, Fabian Ruch wrote:
> pick and reword are atomic to-do list commands in the sense that they
> open a new task which is closed after the respective command is
> completed. squash and fixup are not atomic. They create a new task
> which is not completed until the last squash or fixup is processed.

I don't understand the distinction that you are attempting to draw
between "atomic" and "non-atomic" commands.  For example, in the
following command list:

    pick 1111111
    squash 2222222
    fixup 3333333

the "pick" command doesn't seem very atomic, because the *end* result of
the three commands is a single commit that is affected by all three
commands.  Furthermore, if we change the example to

    pick 1111111
    squash --reset-author 2222222
    fixup --signoff 3333333

then isn't it clear that the user's intention was to apply both options,
"--reset-author" and "--signoff", to the resulting commit?  In other
words, it seems to me that any options on such a chain of lines should
be collected and applied to the final commit as a whole.

> Lift the general unknown option blockade for the pick and reword
> commands. If `do_cmd` comes across one of the options `--signoff` and
> `--reset-author` while parsing a to-do entry and the scheduled
> command is either `pick` or `reword`, relay the option to `do_pick`.

The new user-exposed options should be documented in the git-rebase(1)
manpage and probably also in the help text that is appended to every
"rebase -i" todo list.

> The `do_pick` options `--gpg-sign` and `--file` are not yet supported
> because `do_cmd` cannot handle option arguments and options with
> spaces at the moment. It is true that edit is one of the atomic
> commands but it displays hash information when the rebase is stopped
> and some options rewrite the picked commit which alters that
> information. squash and fixup still do not accept user options as the
> interplay of `--reset-author` and the author script are yet to be
> determined.
> [...]

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu