mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Adam Dinwoodie <>
Cc: Christian Couder <>
Subject: [RFC PATCH v2 0/2] bisect: add a single command for editing logs
Date: Mon, 20 Nov 2017 18:24:37 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

- 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

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

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


  parent reply	other threads:[~2017-11-20 18:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08 13:59 [RFC PATCH] rebisect: add script for easier bisect log editing Adam Dinwoodie
2017-11-08 16:12 ` Christian Couder
2017-11-08 16:15   ` Christian Couder
2017-11-08 16:50     ` Adam Dinwoodie
2017-11-08 16:32   ` Adam Dinwoodie
2017-11-20 18:24 ` Adam Dinwoodie [this message]
2017-11-22  5:35   ` [RFC PATCH v2 0/2] bisect: add a single command for editing logs Junio C Hamano
2017-11-20 18:24 ` [RFC PATCH v2 1/2] bisect: split out replay file parsing Adam Dinwoodie
2017-11-20 18:24 ` [RFC PATCH v2 2/2] bisect: add "edit" command Adam Dinwoodie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).