git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Ramkumar Ramachandra <r@artagnon.com>,
	Git List <git@vger.kernel.org>,
	Christian Couder <christian.couder@gmail.com>
Subject: Re: git bisect bad @
Date: Wed, 12 Jan 2022 09:50:12 -0800	[thread overview]
Message-ID: <xmqq35lsyhbf.fsf@gitster.g> (raw)
In-Reply-To: <3dade45b-494f-663b-264b-06a51ea1cf56@web.de> ("René Scharfe"'s message of "Wed, 12 Jan 2022 10:04:28 +0100")

René Scharfe <l.s.r@web.de> writes:

> It would be nice if we could determine if the command was not found by
> the shell and halt the bisection.  This is actually indicated by the
> shell using error code 127.  However, the script itself could also exit
> with that code (e.g. if one of its commands was not found).  Currently
> this is interpreted as a bad revision and bisection continues, as
> documented in the man page of git bisect.
>
> If we'd make error code 127 (and 126) special by stopping the bisection
> (like we do for 128 and higher) then scripts that relied on that code
> indicating a bad revision would require a manual "git bisect bad" at
> each affected step.  Annoying, but not dangerous.  Such a script would
> have to be modified to convert codes 126 and 127 to e.g. 1.
>
> Seems like a reasonable trade-off to me.  Thoughts?

Probably.  It is safer than the current "all revisions including the
bottom one and the top one are bad" which leads to the "merge-base
says your good and bad are nonsense" error for the "command not
found" case, but what if the one that reports an error with 127 (or
126) is coming from something other than shell (i.e. the 'bisect
run' command was fed is not a script at all)?  Is it a no-no for a
random binary that is not an implementation of shell to exit with
these error status?

>> This presents another possible opportunity for enhancement: in an
>> overwhelmingly large majority of the use cases (or so I assume), './'
>> is really redundant.
> Adding the current directory to $PATH would be inconsistent and might
> even be dangerous.
>
> Prepending "./" to a given command that contains no directory separator
> is speculative -- what if that command is actually found in $PATH?

Bad idea.

> Additionally we could check for the command in the current directory
> and suggest something like "'bisect.sh' not found; did you mean
> './bisect.sh'?".

It may not hurt but I do not think it is necessary at all, as long
as the "halt the 'bisect run' session upon 126 and 127" 

  reply	other threads:[~2022-01-12 17:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-09 19:29 git bisect bad @ Ramkumar Ramachandra
2022-01-09 19:54 ` Junio C Hamano
2022-01-09 20:48   ` Ramkumar Ramachandra
2022-01-10  9:01     ` [PATCH] bisect: report actual bisect_state() argument on error René Scharfe
2022-01-10 10:04       ` Ramkumar Ramachandra
2022-01-10 17:06     ` git bisect bad @ Junio C Hamano
2022-01-10 21:04       ` Ramkumar Ramachandra
2022-01-12  9:04         ` René Scharfe
2022-01-12 17:50           ` Junio C Hamano [this message]
2022-01-12 18:34             ` René Scharfe
2022-01-13  5:10               ` René Scharfe
2022-01-13  9:32                 ` Ramkumar Ramachandra
2022-01-13 12:28                   ` Christian Couder
2022-01-13 13:55                     ` René Scharfe
2022-01-13 15:16                       ` Ramkumar Ramachandra
2022-01-14  7:47                         ` René Scharfe
2022-01-14  8:04                           ` Ramkumar Ramachandra
2022-01-18 12:45                             ` René Scharfe
2022-01-14 18:42                           ` Junio C Hamano
2022-01-13 18:40                       ` Junio C Hamano
2022-01-18 12:45     ` [PATCH v2 1/4] bisect--helper: report actual bisect_state() argument on error René Scharfe
2022-01-18 12:46     ` [PATCH v2 2/4] bisect--helper: release strbuf and strvec on run error René Scharfe
2022-01-18 12:46     ` [PATCH v2 3/4] bisect: document run behavior with exit codes 126 and 127 René Scharfe
2022-01-18 12:46     ` [PATCH v2 4/4] bisect--helper: double-check run command on exit code " René Scharfe
2022-01-19  2:36       ` Junio C Hamano
2022-01-19  7:52         ` René Scharfe
2022-02-04  0:42       ` Junio C Hamano
2022-02-04 17:16         ` René Scharfe
2022-02-04 18:16         ` Ramkumar Ramachandra
2022-02-04 19:32           ` Junio C Hamano
2022-02-04 18:09       ` Ramkumar Ramachandra

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq35lsyhbf.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=r@artagnon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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).