| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Next up is using threads
|
|
Fixes #140
|
|
See #177
|
|
|
|
|
|
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
|
|
However, StringIO really is ByteIO in most cases, and py2.7 should
run but doesn't.
This should be made work first.
|
|
More to come, especially when it's about strings
|
|
All performance tests still print to stderr, but do so in a py3 compatible way
|
|
There is more work to do though, as many imports are still incorrect.
Also, there are still print statements
|
|
* 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/
|
|
Git utilizes multiple environment variables to control various
behaviours. Make sure to set LC_MESSAGES on a copy of the environment
instead of discarding any variables that may be set by the user or
default shell environment such as EDITOR.
Add test to assert that when overriding GIT_EDITOR via os.environ that
the modified value will be picked up by and git commands called.
|
|
boppreh-patch-1
Adjusted patch to only run git command in shell mode on windows.
Conflicts:
git/cmd.py
|
|
Remove Byte Order Mark from git/cmd.py
|
|
The Unicode Byte Order Mark is usually unwanted. git/cmd.py had one
inserted in 2008 by cf37099e, a commit that fix a Windows related issue
which indicate the file has most probably be edited with a text editor
that automatically insert the Byte Order Mark.
Remove the BOM from git/cmd.py
For details aboute the BOM:
https://en.wikipedia.org/wiki/Byte_order_mark
|
|
W291 trailing whitespace
|
|
E261 at least two spaces before inline comment
|
|
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
|
|
The lines were added in commit b38020ae , and I might consider a patch release soon
or get ready with 0.3.3. Lets hope not too many installations will be affected.
|
|
Merged fd leaks fix from the master to the 0.3 version
|
|
Ensure consistent output from git command
|
|
Fix the `git version` parser.
|
|
GitRunCommand exception can store stdout output too.
|
|
(cherry picked from commit ca2b901e7229fc5c793762fd4e4c1c38c5a78e80)
|
|
Some git commands, like git merge outputs their problems onto stdout,
instead of stderr, which will be thrown away by the current setup. This
change allows the GitPython commands to store the stdout's value too,
in case of error.
|
|
|
|
The git command output can vary by language which would cause assertions
errors when parsing the output.
On POSIX system the language used by git can be adjusted by LC_MESSAGES.
The special language 'C' is guaranteed to be always available and is
whatever default the software has been written in (usually english, the
case for git).
Thus passing LC_MESSAGES to Popen will ensure we receive from git a
consistent output regardless of the user preference.
Addresses #153
|
|
Add __call__ method to Git object to allow
passing git command options to the executable
requires flag to transform_kwargs
add unit test
Change-Id: If1bc01008e66d3fd3811c15b56e58f38c95b9887
|
|
Add __call__ method to Git object to allow
passing git command options to the executable
Change-Id: If1bc01008e66d3fd3811c15b56e58f38c95b9887
|
|
When command run as subprocess, AutoInterrupt will kill the
process on destructor. However, if process already finished,
it raise OSError exception.
This fix just ignore OSError on os.kill.
Conflicts:
git/cmd.py
|
|
Currently if command is called with as_proces=True, pipes for the
command will not be closed.
This change makes sure to close command file descriptors.
Conflicts:
git/cmd.py
|
|
probably a good idea to go a little more pep8 (and fix sins of my youth ;) )
|
|
By adding `shell=True,` to the list of Popen parameters, we avoid spawning console windows when scripts call this method from a windowless (.pyw) Python script.
|
|
|
|
installation puts it into the path, instead of git.exe. Of course we warn about the performance penalty that goes with it. Fortunately, using a wrapped git.exe works when creating pipes to the process, admittedly I was a bit surprised by this.
fixes #26
|
|
|
|
thanks to the rpartition method. omg
|
|
|
|
|
|
including test
|
|
the error was caused by PySide which, when instantiating a QApplication, changed the signal handlers to interrupt, instead of retry operating system calls, which caused git-python to fail subsequently. signal.siginterrupt can be used to fix this behaviour after an QApplication was instatiated.
|
|
specific subprocess bug occurs.
|
