You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running the command manually succeeded. Not sure why git would fail with an exit code of 128 and not emit any output. Oh, because the code swallows the output.
@jaraco how is git put on your PATH? It looks like shell=True isn't set which would mean that if you're adding git through e.g. .bashrc it wouldn't be available to subprocess.
I'm on macOS 10.13.6 with git 2.18.0 in /usr/local/bin as installed by homebrew. And I use programs dozens of times daily that invoke subprocess.Popen(['git', ...]) (manly setuptools_scm).
I honestly can't imagine what might have gone wrong.
I tried running the command a couple more times (same as before), but this time didn't encounter the error.
Still, I wonder if it would be better to let the output from the git invocation be piped directly to stdout/stderr:
core-workflow master $ git diff
diff --git a/blurb/blurb.py b/blurb/blurb.py
index 10dac4d..001c7bd 100755
--- a/blurb/blurb.py
+++ b/blurb/blurb.py
@@ -697,7 +697,7 @@ def chdir_to_repo_root():
# find the root of the local CPython repo
# note that we can't ask git, because we might
# be in an exported directory tree!
-
+
# we intentionally start in a (probably nonexistant) subtree
# the first thing the while loop does is .., basically
path = os.path.abspath("garglemox")
@@ -1108,14 +1108,14 @@ Python News
git_add_files = []
def flush_git_add_files():
if git_add_files:
- subprocess.run(["git", "add", "-f", *git_add_files], stdout=subprocess.PIPE, stderr=subprocess.PIPE).check_returncode()
+ subprocess.run(["git", "add", "-f", *git_add_files]).check_returncode()
git_add_files.clear()
git_rm_files = []
def flush_git_rm_files():
if git_rm_files:
try:
- subprocess.run(["git", "rm", "-f", *git_rm_files], stdout=subprocess.PIPE, stderr=subprocess.PIPE).check_returncode()
+ subprocess.run(["git", "rm", "-f", *git_rm_files]).check_returncode()
except subprocess.CalledProcessError:
pass
Or if there's some reason to capture the output (there isn't any output at all in my use case), use that output when reporting an exception.
I can see there is some output from git rm that would be suppressed by the PIPE parameter. Perhaps better would be to use git rm -q if blurb wishes for the command to run with minimal output.
JFYI $ git rm -f non-existing-file returns code 128. This could've happened because of double-run of this command on the same file, for example. (First run removes file from fs successfully with rc 0, second fails to locate it and returns 128)
Activity
jaraco commentedon Jul 13, 2018
Running the command manually succeeded. Not sure why git would fail with an exit code of 128 and not emit any output. Oh, because the code swallows the output.
jaraco commentedon Jul 13, 2018
Running a second time with pdb, I did not encounter the error (though I did encounter another error):
brettcannon commentedon Jul 13, 2018
@jaraco how is git put on your PATH? It looks like
shell=Trueisn't set which would mean that if you're adding git through e.g..bashrcit wouldn't be available tosubprocess.jaraco commentedon Jul 14, 2018
I'm on macOS 10.13.6 with
git2.18.0 in/usr/local/binas installed by homebrew. And I use programs dozens of times daily that invokesubprocess.Popen(['git', ...])(manly setuptools_scm).I honestly can't imagine what might have gone wrong.
I tried running the command a couple more times (same as before), but this time didn't encounter the error.
Still, I wonder if it would be better to let the output from the git invocation be piped directly to stdout/stderr:
Or if there's some reason to capture the output (there isn't any output at all in my use case), use that output when reporting an exception.
jaraco commentedon Jul 14, 2018
I can see there is some output from
git rmthat would be suppressed by the PIPE parameter. Perhaps better would be to usegit rm -qif blurb wishes for the command to run with minimal output.Allow stdout and stderr to play through the standard pipes such that …
webknjaz commentedon Jul 17, 2018
JFYI
$ git rm -f non-existing-filereturns code128. This could've happened because of double-run of this command on the same file, for example. (First run removes file from fs successfully with rc 0, second fails to locate it and returns 128)webknjaz commentedon Jul 17, 2018
Also, this happens to untracked files (not
git added):jaraco commentedon Jul 17, 2018
The original error I hit was during git add.
webknjaz commentedon Jul 17, 2018
git adding non-existing file is also128.