| Age | Commit message (Collapse) | Author |
|---|
|
+ Simplify call_process, no win-code case, no `make_call()` nested func.
+ Del needless WinError try..catch, in `_call_process()` already
converted as GitCommandNotFound by `execute()`.
+ pyism: kw-loop-->comprehension, facilitate debug-stepping
|
|
+ see
http://help.appveyor.com/discussions/problems/5334-nosetests-finsih-bu-build-stuck-and-next-job-dealys-to-start
+ Use `io.DEFAULT_BUFFER_SIZE`.
+ test_commit: replace asserts with unittest-asserts.
- TRY Popen() NO universal_newlines: NO, reverted in next commits.
+
[travisci skip]
|
|
|
|
+ FIXED most hangs BUT no more `git-daemon` un-killable!
+ Use logger for utils to replace stray print().
|
|
|
|
+ The code in `_read_lines_from_fno()` was reading the stream only once
per invocation, so when input was larger than `mmap.PAGESIZE`, bytes
were forgotten in the stream.
+ Replaced buffer-building code with iterate-on-file-descriptors.
+ Also set deamon-threads.
|
|
+ Del extra spaces, import os.path as osp
|
|
It's entirely untested if this repo still does the right thing,
but I'd think it does.
Fixes #504
|
|
|
|
|
|
|
|
This fixes a UI problem with using GitPython from a GUI python probgram.
Each repo that is opened creates a git cat-file processs and that provess will create
a console window with out this change.
|
|
|
|
|
|
Just went through all changes and adjusted them to the best of my
abilities. As there are no tests to claim otherwise, I believe
this is correct enough.
However, it becomes evident that it's no longer possible to just
make changes without backing them with a respective test.
|
|
Convert to the expected bytes.
|
|
|
|
pr-cmd-raise-with-stderr-on-error
|
|
|
|
remove stderr for a wait() that is not the GitPython wrapper.
|
|
|
|
(instead of abusing the "short-circuit" property of logical operations)
|
|
That way, real-time parsing of output should finally be possible.
Related to #444
|
|
pix Py2.6 compatibility
|
|
Admittedly this fix is solely based on the documentation provided
for this parameter, which indicated a different intend than was
actually implemented. Also I don't believe doing this will cause
any harm.
As a special note: the call to `open(os.devnull, 'wb')` does not seem leak
the handle, apparently it is given as-is to the subprocess, which will then
close it naturally. This was tested using an interactive session via `htop`
on osx.
Fixes #437
|
|
Fixes #435
|
|
Since Python 3.3, the hash value of an object is seeded randomly, making it
change between each call. As a consequence, the `dict` type relying on the hash
value for the order of the items upon iterating on it, and the parameters
passed to `git` being passed as `kwargs` to the `execute()` method, the order
of parameters will change randomly between calls.
For example, when you call `git.remote.pull()` in a code, two consecutives run
will generate:
1. git pull --progress -v origin master
2. git pull -v --progress origin master
Within the `transform_kwargs()` method, I'm promoting `kwargs` into an
`collections.OrderedDict` being built with `kwargs` sorted on the keys.
Then it will ensure that each subsequent calls will execute the
parameters in the same order.
|
|
Some Git command line options are allowed to be repeated multiple times.
Examples of this are the -C flag which may occur more than once to
"strengthen" its effect, or the -L flag on Git blames, to select
multiple blocks of lines to blame.
$ git diff -C -C HEAD~1 HEAD
$ git blame -L 1-3 -L 12-18 HEAD -- somefile.py
This patch supports passing a list/tuple as the value part for kwargs,
so that the generated Git command contain the repeated options.
|
|
|
|
Popen defaults to using unbuffered reads, which are extremely slow.
|
|
Related to #383
|
|
Thanks travis, once again !
|
|
Fixes #383
|
|
We keep stdout closed, which seems to have the side-effect of
stdout being connected to your TTY, in case you run a terminal.
However, this shold also prevent deadlocks, as only stderr is used.
The alternative would have been to try to fetch lines concurrently,
and we have been there.
For clone(), `communicate()` is used, and with some luck this will
just do the right thing. Even though last time I checked, it
didn't ... ? Lets see.
Stab at #72
|
|
signal.SIGKILL is not available on Windows so use signal.SIGTERM as a backup
when SIGKILL is not available.
|
|
Include 'timeout' parameter in Git execute
|
|
|
|
Related to #357
|
|
|
|
Fixed deadlock when using stderr=PIPE in Popen and Git generates enough
output to a pipe such that it blocks waiting for the OS pipe buffer to
accept more data (see
https://docs.python.org/2/library/subprocess.html#subprocess.Popen.wait)
|
|
Right now, we come out of the iteration in case of failure
while trying to kill a child pid. This may result in some of
the child pids staying alive.
Change-Id: I18d58fcefec2bbdae4ae9bf73594939ade241b52
|
|
Specify that this feature is not supported on Windows and
mention about the negative side-effects of SIGKILL on a
repository.
Change-Id: Ibba2c3f51f84084b4637ae9aaafa87dd84000ef4
|
|
Change-Id: I8ab3d5affb3f040dd9630687fb20aedbd7510070
|
|
If the timeout is not specified, we don't need the overhead of
creating a watchdog and event.
Change-Id: I53ff891af24d4c27fb16bf4bb35910dd1d19d238
|
|
Change-Id: I2e081c606b75b7f8d3d1ee82d93c3d9f3bdcfcbe
|
|
This feature enables to set a timeout while executing a git
command. After this timeout is over, the process will be killed.
If not explicitly specified, the default functionality will not
be affected.
Change-Id: I2dd5f0de7cb1f5f1b4253dd7ce92d23551d5f9a7
|
|
for the executable.
|
|
This allows us to use the main thread to parse stderr to get progress,
and resolve assertion failures hopefully once and for all.
Relates to #301
|
|
* Previously we could fail to parse the last line within a read buffer,
which is now fixed.
* Added a test to verify our *slow* line parsing works as expected.
|
|
When the code is run without setting up loggers, the loggers have no
handlers for the emitted messages. The logging module displays:
`No handlers could be found for logger "git.cmd"` on the
console. By adding a NullHandler (a no-op) the message disappears,
and doesn't affect logging when other handlers are configured.
|
