Christian Couder <chriscool@xxxxxxxxxxxxx> writes:
> This patch refactors rev parsing code in a new "bisect_parse_rev"
> function, and adds warnings in case a rev with a name that is the
> same as one of the bisect subcommands is given where a revision
> is expected.
>
> Signed-off-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
> ---
> git-bisect.sh | 47 ++++++++++++++++++++++++++++++------------
> t/t6030-bisect-porcelain.sh | 21 +++++++++++++++++++
> 2 files changed, 54 insertions(+), 14 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 6b43461..a090b97 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -61,6 +61,31 @@ bisect_autostart() {
> }
> }
>
> +bisect_parse_rev() {
> + rev="$1"
> + dont_die_on_wrong_rev="$2"
> + name="$rev^{commit}"
> + dubious_rev_name=''
> +
> + case "$rev" in
> + HEAD)
> + name='HEAD' ;;
> + help|start|bad|good|skip|next|reset|visualize|replay|log|run)
> + dubious_rev_name='yes' ;;
> + esac
I see you listed all the subcommand names here but I somehow doubt this is
sensible.
The "bisect good $foo bad $bar" example from Ingo's transcript may suggest
that good/bad may incorrectly appear by copying and pasting from an
incorrect how-to guide, but on the other hand "bisect bad log" to mark the
tip of the "log" branch (or "replay or any other common words) to see
where in the development trail on that branch things got broken is a
perfectly valid and plausible thing to do. Also when you happen to have
found something broken while you are working on a more important issue,
you may tentatively do "git tag bad $it", and keep working on that
important issue, only to come back later and use that lightweight tag to
feed "git bisect" with. In either use case, "you named your ref the same
as bisect subcommand name, bad boy" is an unnecessary noise.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
