| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
* GIT_PYTHON_TRACE now behaves correctly for fetch, and pull (i.e. if as_process is used)
* Improved parsing of fetch head information
However, there is still a messy bit that tries to bring together fetch progress information
with fetch head information. Even though it works now, an alternative implementation should
be attempted.
|
| |
|
|
|
|
|
| |
Commandline was
autopep8 -j 8 --max-line-length 120 --in-place --recursive --exclude "*gitdb*,*async*" git/
|
|
|
|
| |
W291 trailing whitespace
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
E201 whitespace after '('
E202 whitespace before ')'
E203 whitespace before ':'
E225 missing whitespace around operator
E226 missing whitespace around arithmetic operator
E227 missing whitespace around bitwise or shift operator
E228 missing whitespace around modulo operator
E231 missing whitespace after ','
E241 multiple spaces after ','
E251 unexpected spaces around keyword / parameter equals
|
|
|
|
|
|
| |
E301 expected 1 blank line, found 0
E302 expected 2 blank lines, found 1
E303 too many blank lines (n)
|
|
|
|
|
|
|
|
|
|
|
| |
W191 indentation contains tabs
E221 multiple spaces before operator
E222 multiple spaces after operator
E225 missing whitespace around operator
E271 multiple spaces after keyword
W292 no newline at end of file
W293 blank line contains whitespace
W391 blank line at end of file
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
johnsca-sf-master
Conflicts:
git/cmd.py
git/objects/commit.py
git/objects/fun.py
git/objects/util.py
git/remote.py
git/repo/base.py
git/test/lib/helper.py
git/test/test_commit.py
git/test/test_fun.py
git/util.py
|
| | |
|
| |
| |
| |
| |
| |
| | |
Git supports fetching many refs at once - support this in GitPython
too for more efficient operations when selectively mirroring
repositories.
|
| | |
|
| | |
|
| |
| |
| |
| | |
probably a good idea to go a little more pep8 (and fix sins of my youth ;) )
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
| |
partial or intermixed lines from the pipe. This really shouldn't be, but its windows so it happens
|
|
|
|
| |
is push, fetch, pull and clone. This allows progress information to be sent in newer git versions without breaking older ones (ideally)
|
| |
|
|
|
|
| |
remote: Fixed bug that was caused by the unchecked deletion of an uncached attribute which did not necessarily exist
|
| |
|
|
adjusted
|