| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
I really never want to touch python again, and never deal with
py2/3 unicode handling anymore.
By now, it seems pretty much anything is better.
Is python to be blamed for it entirely ?
Probably not, but there are better alternatives.
Nim ? Rust ? Ruby ?
Totally
|
|
|
|
|
|
|
|
|
| |
This issue only surfaced in python 2, in case paths containing unicode
characters were not actual unicode objects.
In python 3, this was never the issue.
Closes #331
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When expanding directories, check if it is a symlink and don't expand
them at all.
Previously, we followed symlinks and expanded their contents, which
could lead to weird index files.
Fixes #302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turned out that the index is not actually corrupted, which is good
news. What happens is that `git` writes `TREE` extension data into the
index, which causes it to write out the given tree *as is* next time
a `git commit` is executed. When using `git add`, this extension data
is maintained automatically. However, GitPython doesn't do that ... .
Usually this is no problem at all, as you are supposed to use
`IndexFile.commit(...)` along with `IndexFile.add(...)`.
Thanks to a shortcoming in the GitPython API, the index was
automatically written out whenever files have been added, without
providing control over whether or not *extension data* will be
written along with it.
My fix consists of an additional flag in `IndexFile.add(...)`, which
causes extension data not to be written by default, so commits can be
safely done via `git commit` or `IndexFile.commit(...)`.
However, this might introduce new subtle bugs in case someone is
relying on extension data to be written. As this can be controlled
through the said flag though, a fix is easily done in that case.
Fixes #265
|
|
|
|
|
| |
However, it doesn't reproduce on the latest version of GitPython.
Maybe it's on an older one.
|
|
|
|
|
| |
Previously, it checked for AssertionErrors, now we have to implement
need-unbare-repo check ourselves.
|
|
|
|
|
|
|
| |
Assured unicode values are supported when reading the configuration,
and when getting author/committer information from the environment.
Fixes #237
|
|
|
|
|
|
|
|
|
| |
However, it does so only on posix. The test-case will run on posix only
as well.
Please note that in theory, even on windows we will attempt to run hooks,
even though I am not sure that this will actually work.
Fixes #81
|
|
|
|
|
|
|
|
| |
used consistently.
This will save IOPs, and make the code easier to understand (I suppose).
Related to #224
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Now it's about going through PY3 issues
|
|
|
|
|
|
| |
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
|
|
|
|
| |
autopep8 -v -j 8 --max-line-length 120 --in-place --recursive
|
|
|
|
|
|
|
| |
* travis configuration adjusted to hopefully work better than before
Performance traversal still fails when using git-python as standard repository.
It naturally wants a larger one. On travis these tests are skipped though.
|
|
|
|
|
| |
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
|
|
|
|
| |
probably a good idea to go a little more pep8 (and fix sins of my youth ;) )
|
|
adjusted
|