| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
nothing's wrong
cf #444
Signed-off-by: Guyzmo <guyzmo+github@m0g.net>
|
| |
| |
| |
| | |
Related to #444
|
| | |
|
| |
| |
| |
| |
| |
| | |
That way, real-time parsing of output should finally be possible.
Related to #444
|
| |
| |
| |
| |
| |
| | |
That way, progress usage will behave as expected.
Fixes #444
|
| |
| |
| |
| |
| |
| |
| | |
Previously, the logic was not correct. Now it should work either way,
truncating the correct list to assure both always have the same length.
Related to #442
|
| |
| |
| |
| | |
Fixes #442
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies the API and removes the parser, RemoteProgres,
from the API as RemoteProgress is an internal detail of the implementation.
progress is accepted as:
* None - drop progress messages
* callable (function etc) - call the function with the same args as update
* object - assume its RemoteProgress derived as use as before
RemoteProgress takes an optional progress_function argument.
It will call the progress function if not None otherwise call self.update
as it used to.
|
| |
|
| |
|
| |
|
|
|
|
| |
Related to #396
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
Previously it was possible for it to pick up non-repository
branch configuration, even though it was unlikely.
Closes #350
|
|
|
|
|
|
| |
Fixed additional test which seems to have different outcomes depending
on the interpreter. This just makes it work withouth attempting
to find the root cause of the issue.
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out we can't deal do fetches if no refspec is set as git
will change the format of the fetch return values, providing less
information than usual.
A test was added to show that such a case will fail, and an assertion
will assure we don't attempt to fetch/pull if there is no refspec
for 'fetch'.
Closes #296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverted changes of `fe2fbc5~2`.
This caused `git-pull` to error, which now actually results in a fatal
error while fetching or pulling. Previously we simply didn't check
for this issue.
Now we are back to a `poll` based or threaded concurrent reading from
stdout and stderr to prevent a git process deadlock, and the
aforementioned error.
Related to #297
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Do not swallow non-zero exit status during push and fetch unless
we managed to parse head information.
This behaviour will effetively handle cases were no work was done
due to invalid refspecs or insufficient permissions.
Fixes #271
|
|
|
|
|
| |
Think about how expensive this single invisible character was, with
all the time and energy spent on it !
|
|
|
|
| |
Fixes #260
|
|
|
|
|
|
| |
While at it, all other invocations of .git in remote.py were reviewed
Fixes #262
|
|
|
|
| |
Fixes #250
|
|\
| |
| |
| |
| |
| | |
Need latest master to proceed with test
Conflicts:
doc/source/tutorial.rst
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even though the test-csae only verifies this spec:
+refs/pull/*:refs/heads/pull/*
I could locally verify that it indeed handles other ones just as well:
+refs/pull/*:refs/pull/*
Fixes #243
|
| |
| |
| |
| |
| |
| | |
That way they are protected from regression.
Fixes #239
|
|/ |
|
|
|
|
|
|
| |
GIT_PYTHON_TRACE would actually fail (now) if we debugged archive operations.
Related to #239
|
| |
|
|
|
|
|
|
|
| |
This simplification should improve performance and remove issues like those
in #232.
NOTE: Debug code is still contained here
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FETCH_HEAD.
This data will be written into the git-repository itself, prefixed with the
number of the operation.
Thus, a test-run with exactly one fetch operation would look like this afterwards:
ls -l .git
total 96
-----> -rw-r--r-- 1 byron staff 141B Jan 16 11:54 000_debug_git-python_FETCH_HEAD <-----
-----> -rw-r--r-- 1 byron staff 180B Jan 16 11:54 000_debug_git-python_stderr <-----
-rw-r--r-- 1 byron staff 487B Jan 16 11:54 FETCH_HEAD
-rw-r--r-- 1 byron staff 22B Jan 16 11:54 HEAD
-rw-r--r-- 1 byron staff 41B Jan 16 11:54 ORIG_HEAD
drwxr-xr-x 2 byron staff 68B Jan 16 11:54 branches/
-rw-r--r-- 1 byron staff 560B Jan 16 11:54 config
-rw-r--r-- 1 byron staff 73B Jan 16 11:54 description
drwxr-xr-x 11 byron staff 374B Jan 16 11:54 hooks/
-rw-r--r-- 1 byron staff 13K Jan 16 11:54 index
drwxr-xr-x 3 byron staff 102B Jan 16 11:54 info/
drwxr-xr-x 4 byron staff 136B Jan 16 11:54 logs/
drwxr-xr-x 12 byron staff 408B Jan 16 11:54 objects/
-rw-r--r-- 1 byron staff 1.2K Jan 16 11:54 packed-refs
drwxr-xr-x 5 byron staff 170B Jan 16 11:54 refs/
[ci skip]
|
|
|
|
|
|
| |
Fixes #7
[ci skip]
|
|
|
|
|
|
|
|
| |
Apparently, thanks to an incorrect version check, PY3 ended up using
a git command object database by default. This is now fixed.
Additionally, the update_cache code was adjusted to check for method-existence,
as it's valid to use object databases which simply don't have a
caching mechanism (like the git command object database)
|
|
|
|
| |
Fixes #34
|
|
|
|
|
|
|
| |
Helps fixing #35
Also, the production status was changed to 'stable', which should
have been done much earlier.
|
| |
|
|
|
|
| |
Fixes #48
|
| |
|
|
|
|
| |
Next up is using threads
|
|
|
|
|
|
|
| |
And I have to wonder why git-daemon serves under py2.7, but really
wants receive-pack to be allowed under 3.4. Maybe it's a repository
override which for some reason doesn't work in py3.4 ? Maybe because
the change is not flushed ?
|
|
|
|
|
| |
Kind of tackling the tasks step by step, picking low-hanging fruit first,
or the ones that everyone depends on
|
|
|
|
| |
More to come, especially when it's about strings
|
|
|
|
|
| |
There is more work to do though, as many imports are still incorrect.
Also, there are still print statements
|
|
|
|
| |
autopep8 -v -j 8 --max-line-length 120 --in-place --recursive
|
|
|
|
|
|
| |
This could however, introduce a chance of an assertion hitting once again
as it has been commented out for quite a long time. Now it's back in a changed form
though, and once again tries to make sure we get proper results
|