[RFC PATCH v2 0/2] bisect: add a single command for editing logs

[Adam Dinwoodie <adam@dinwoodie.org>]

When I'm bisecting, I sometimes want to edit the bisection log, e.g. to
remove the "skip" marker by a commit I've now found a way to avoid
skipping.  Rather than requiring users to save off the log, edit it,
then replay the edited log as separate commands, this patch series adds
support for a "git bisect edit" command which does all three steps in
one.

Christian Couder has already said he's happy with the broad idea in the
previous spin of this RFC, so here's a first attempt at actually
implementing the function within "git bisect".

There are a few issues of varying significance before I think this is
ready to be actually used.  I'm not sure how to approach them, and would
be very grateful for advice from the list:

- It's possible to start a bisect session with a command like `git
  bisect @ @~10`.  This will lead to the bisect log including the `@`
  and `@~10` literally, and the interpretation of those values changes
  depending on the current HEAD.  As a result, if you do a `git bisect
  edit` after starting a bisect like that, but don't actually edit the
  file, you'll nonetheless be in a different state.

  I can see a few ways of coping with that:

  1. Change the existing `git bisect start` behaviour to run arguments
     through `git rev-parse` before recording them.  It appears `git
     bisect good` et al. already do that, but it is a change in
     behaviour that I guess could impact badly on other people using
     `git bisect log`-based workflows.

  2. Do a full `git bisect reset` before replaying the log, so the
     revisions will be parsed in the same way as they were originally.
     I'd be slightly sad about that, as it seems an unnecessary
     inefficiency, but it may well be the simplest approach.

  3. Somehow get Git to parse the relative references as relative to the
     original commit rather than the current HEAD.  I'm not sure if
     there's code for doing this already, but if not I suspect it's
     beyond my ability to implement in the immediate term.

  4. Just detect when users are in this scenario, and warn them that
     Git's behaviour might be unexpected.

- I can see `git rebase --interactive` detects when the edited file
  hasn't changed, and in that case prints a success message but
  otherwise takes no action.  I've not implemented that behaviour here
  because I couldn't immediately work out how rebase does it, and I
  didn't want to reinvent that particular wheel.  (Plus I think the
  impact of performing such unnecessary steps will be considerably lower
  than the equivalent with rebase.)

- I'm not entirely happy with the error handling, primarily as I
  couldn't seem to find a consensus on what best practice is for
  handling errors between the existing shell code in this script and
  git-rebase--interactive.sh.

- There aren't yet any tests or documentation changes; I wanted to get
  commentary on the initial code changes before I spent time on those
  parts.

Adam Dinwoodie (2):
  bisect: split out replay file parsing
  bisect: add "edit" command

 builtin/bisect--helper.c |  3 ++-
 git-bisect.sh            | 25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

-- 
2.15.0.281.g87c0a7615