blame: allow user to specify rev arguments to blame #439
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The options parser for blame is currently quite strict, and
can handle only a single positive revision in opt_rev_args.
But there are several parsing problems with this:
1. If you run "tig blame --reverse foo.c", the "--reverse"
flag ends up in opt_rev_args (filter_options knows it's a
flag, but since it is a revision flag, it gets put
there).
We try to access "--reverse.c:foo.c", which is
nonsensical. Moreover, if you did specify a start-point
like "HEAD foo.c", tig will complain that you have more
than one revision arg.
2. If you run "tig blame --since=123", this is converted by
"rev-parse --revs-only" to "--max-age=123", and is
included in opt_rev_args, and you run into the same
problems as above.
3. If you run "tig blame HEAD~20..HEAD", the commit range
is split into two arguments, "HEAD" and "^HEAD~20", both
of which end up in opt_rev_args. Similarly, the user can
specify this "split" form themselves.
We can fix this by further parsing opt_rev_args. Instead of
assuming that it must contain zero or one arguments, we can
pick out the "positive" ref as our starting point (and
complain if there is more than one).
The rest of the rev-args we add to %(blameargs), so that
git-blame can act on them.
jonas
added a commit
that referenced
this pull request
Sep 15, 2015
blame: allow user to specify rev arguments to blame
|
Awesome, thanks. |
zevv
added a commit
to zevv/tig
that referenced
this pull request
Jun 19, 2017
branch, but the graph gives the impression the commit is not merged. The old case rendered this result. Not that the bottom branch looks like it terminates without being merged: ● Update NEWS with post 2.1.1 changes ●─╮ Merge pull request jonas#457 from vivien/text-variable │ ● add a %(text) variable ●─╯ Merge pull request jonas#439 from peff/fix-blame-args │ ● blame: allow user to specify rev arguments to blame ●─╯ Update OSX make config to find brew installed ncurses ● Remove unneeded calls to {def,reset}_prog_mode With fix I get this: ● Update NEWS with post 2.1.1 changes ●─╮ Merge pull request jonas#457 from vivien/text-variable │ ● add a %(text) variable ●─┤ Merge pull request jonas#439 from peff/fix-blame-args │ ● blame: allow user to specify rev arguments to blame ●─╯ Update OSX make config to find brew installed ncurses ● Remove unneeded calls to {def,reset}_prog_mode Related to jonas#419 My current solution is not nice: it depends on the order of evaluation in the graph_symbol_to_XXX() functions so that the new case of graph_symbol_merge_branch() is hit before graph_symbol_turn_left() or graph_symbol_merge() do. The graph-generating code is complex, and I have not spent enough time in it to know for sure my fix does not mess up other situations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The options parser for blame is currently quite strict, and can handle only a single positive revision in opt_rev_args. But there are several parsing problems with this:
If you run
tig blame --reverse foo.c, the--reverseflag ends up in opt_rev_args (filter_options knows it's a flag, but since it is a revision flag, it gets put there).We try to access
--reverse.c:foo.c, which is nonsensical. Moreover, if you did specify a start-point likeHEAD foo.c, tig will complain that you have more than one revision arg.If you run
tig blame --since=123, this is converted byrev-parse --revs-onlyto--max-age=123, and is included in opt_rev_args, and you run into the same problems as above.If you run
tig blame HEAD~20..HEAD, the commit range is split into two arguments,HEADand^HEAD~20, both of which end up in opt_rev_args. Similarly, the user can specify thissplitform themselves.We can fix this by further parsing
opt_rev_args. Instead of assuming that it must contain zero or one arguments, we can pick out the "positive" ref as our starting point (and complain if there is more than one).The rest of the rev-args we add to
%(blameargs), so that git-blame can act on them.