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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename
Exponential
backoff toQuadratic
#1815Rename
Exponential
backoff toQuadratic
#1815Changes from all commits
d737c4a
bf4fa1b
6990f76
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am looking forward to that!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I'm looking forward to it, actually. I'm not sure if
shell()
currently works properly in all the cases listed in #1761 where it reasonably should. But one case listed there that I expect it can and should be made to work--if it doesn't work already--is BusyBox-based MinGit. For that, there would not be abash.exe
in the same directory as thesh
implementationshell()
should find.I look forward more to the possibility that
gix-path
--or somegix-*
crate, since maybe this is actually in the ambit ofgix-command
--could report the locations of more executables.sh
should be preferred overbash
for running shell scripts even when they are identical executables or one is a symlink to the other--becausebash
, and most other Bourne-style shells, behaves more POSIX-compatibly when invoked by the namesh
. Yet finding and runningbash
is something that is often reasonable to do for specific reasons. It is a better choice in the gitoxide test suite, because the fixture scripts usebash
-specific language features and they are not currently run in a way where their#!
lines are automatically respected. There may even be some applications that need to usebash
to run scripts that ideally should run insh
, just because they have been doing that for a long time already and users rely on it.There are also various other executables that are often but not always available, and are relevant to Git, that are not found in the same directories as the Git for Windows
sh.exe
andbash.exe
. An important case isperl
. (MinGit does not haveperl
, but full Git for Windows installations do ship it, and I think it could be useful to find the one that comes with Git for Windows.)More broadly, this could be part of a way of figuring out how to run interpreters specified in
#!
lines. Perhaps we should also have a function ingix-path
, or somewhere. that takes a command name, to which"bash"
could be passed.Edit: Or maybe this is actually an alternative search behavior that should be achieved by opting into it through
gix_command::Prepare
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks for sharing! Finding binaries isn't straightforward and having read this, I'd be glad if providing such functionality in
gix-*
crates would be minimised, strictly limited to strong use-cases or demands.If I remember correctly, on Windows this is already done via
gix-command
. But I don't recall if anything special is done to launch the command specified in the shebang. but think the implementation closely follows the one in Git.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gix-command
attempts to interpret shebangs, but I don't think it does so using the environment modifications Git for Windows puts in place. Traditionally Git for Windows did this in thegit.exe
shim but not the realgit.exe
executable that the shim points to. But since git-for-windows/git#2506 the realgit.exe
will detect when it looks like the customizations were not made and do them itself.For
PATH
customizations especially, I think it might not be good to perform them or act by default as though they have been done. The kind of thing it does now, searching the preexistingPATH
, seems better. Applications that usegix-*
crates may run on Windows systems where Git for Windows is absent. Even when it is present, it is not clear that interpreters for hooks should in general be searched for first in Git for Windows related directories. There is also the subtlety that some executables found in directories Git for Windows adds to thePATH
might malfunction in some uses if run without that environment set.So while I think this may be useful functionality, it should probably continue not to be the default, and be some combination of opt-in and/or enabled automatically only for interpreters that are very likely to be wanted from Git for Windows. This might just be
sh
, butbash
(which is alongsidesh
) andperl
(which is not) are plausible others.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for sharing, I wasn't aware that
git.exe
auto-modifies itsPATH
, something which indeed isn't done ingix-command
. I also agree that it shouldn't be done by default, even though it might be useful to have at some point for opting in.For now I assume that
sh.exe
used by Git will automatically allow all sibling commands to be called as well, which should make shell scripts on Windows more usable overall.