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
