| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Previously, the following fields on Diff instances were assumed to be
passed in as unicode strings:
- `a_path`
- `b_path`
- `rename_from`
- `rename_to`
However, since Git natively records paths as bytes, these may
potentially not have a valid unicode representation.
This patch changes the Diff instance to instead take the following
equivalent fields that should be raw bytes instead:
- `a_rawpath`
- `b_rawpath`
- `raw_rename_from`
- `raw_rename_to`
NOTE ON BACKWARD COMPATIBILITY:
The original `a_path`, `b_path`, etc. fields are still available as
properties (rather than slots). These properties now dynamically decode
the raw bytes into a unicode string (performing the potentially
destructive operation of replacing invalid unicode chars by "�"'s).
This means that all code using Diffs should remain backward compatible.
The only exception is when people would manually construct Diff
instances by calling the constructor directly, in which case they should
now pass in bytes rather than unicode strings.
See also the discussion on
https://github.com/gitpython-developers/GitPython/pull/467
|
|
|
|
Relates to #446
|
|
|
|
|
|
This catches the case where the matched line contains "(" or ")"
characters.
|
|
|
|
The diff --patch parser was missing some edge case where Git would
encode non-ASCII chars in path names as octals, but these weren't
decoded properly.
\360\237\222\251.txt
Decoded via utf-8, that will return:
💩.txt
|
|
Related to #450
|
|
|
|
|
|
Don't allow `, ` prefixes or suffixes in messages.
Fixes #438
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In response to
https://github.com/gitpython-developers/GitPython/pull/408/files/5de21c7fa2bdd5cd50c4f62ba848af54589167d0..aae2a7328a4d28077a4b4182b4f36f19c953765b#r59722704
|
|
|
|
|
|
For more information, see CHANGES.rst
Fixes #369
|
|
This should fix resource leaking issues once and for all.
Related #304
|
|
Previously timezones which were not divisable by 3600s would be
parsed correctly, but would serialize into a full hour, rounded up.
Now floating point computation is used which fixes the issue.
Related to #336
|
|
|
|
|
|
|
|
|
|
|
|
very small typo in changelog. Reop -> Repo
|
|
Just to declare the motivation behind this version jump, and state
it is similar to v0.3.7.
|
|
* milestone URL: http://goo.gl/HFaeZ4
|
|
They didn't show up as code-block
Related to #256
|
|
|
|
It goes along with the new one advertising the GIT_SSH_COMMAND
environment variable.
Related to #256
|
|
... if it is not found. Previously, especially on windows, this wasn't
explicit.
Fixes #248, affects #126
|
|
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
|
|
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
|
|
|
|
Also move untestable documentation out of test.
Related: #234, #242
|
