| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds 2 properties to commits. Their values are derived from the
existing data stored on them, but this makes them more conveniently
queryable:
- authored_datetime
- committed_datetime
These return "aware" datetimes, so they are effectively companions to
their raw timestamp equivalents, respectively `authored_date` and
`committed_date`.
These datetime instances are convenient structures since they show the
author-local commit date and their UTC offset.
|
|
|
|
|
|
|
|
|
|
| |
The problem is that a per-tree modification API cannot work properly, as the sorting is based
on full paths of all entries within the repository. This feat can only be achieved by the index,
which to my knowledge already does it correctly.
The only fix is to remove the misleading API entirely, which will happen in the next commit.
Related to #369
|
|
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
|
| |
Previously it was possible to generate trees which didn't
appear legit to git as gitpython's sorting was a simple alpha-numeric
sort. Git uses one that minimizes literal string comparisons though,
and thus behaves slightly differently sometimes.
Fixes #369
|
|
|
|
| |
Related to #362
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Without this commit the update() function of a submodule does not work
in CentOS 6.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
When the code is run without setting up loggers, the loggers have no
handlers for the emitted messages. The logging module displays:
`No handlers could be found for logger "git.cmd"` on the
console. By adding a NullHandler (a no-op) the message disappears,
and doesn't affect logging when other handlers are configured.
|
| |
|
|
|
|
|
|
|
|
| |
On Windows, `repo.create_submodule(...)` failed because git didn't recognize
the worktree path set in `.git/modules/sub/config` (`fatal: bad config file
line 6 in ./config`). This commit makes `_write_git_file_and_module_config`
convert the worktree path to the linux format (forward slashes) which git
recognizes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In repositories like
> git branch -a
* test
> ls
test
`repo.iter_commits` failed due to an ambigous argument
(`'git rev-list test`).
Now this cannot happen anymore.
fixes #264
|
| |
|
|
|
|
|
|
|
| |
As I am pretty sure to have tested it with 1.7.0, I assume they
added the git file feature somewhere between .0 .10.
Fixes #252
|
|
|
|
| |
It's new in the latest version of flake - thanks travis for letting me know.
|
|
|
|
|
|
| |
That, over time, could have caused slow downs due to file-system hassle.
Fixes #258
|
|
|
|
|
|
| |
That way they are protected from regression.
Fixes #239
|
|
|
|
|
| |
Previously, it checked for AssertionErrors, now we have to implement
need-unbare-repo check ourselves.
|
|
|
|
|
|
| |
GIT_PYTHON_TRACE would actually fail (now) if we debugged archive operations.
Related to #239
|
|
|
|
|
|
| |
Now travisci tests should work once again.
Related to #239
|
|
|
|
|
|
|
|
|
| |
Previously we could try to remove the branch we are on.
Of course, we have a test-case elaborate enough to verify we don't
destroy changes in submodules accidentally. Therefore I am confident
that this implementation is correct.
Fixes #49
|
|
|
|
|
| |
The latter happened as now BadName is thrown, instead of BadObject.
Changes.rst was marked accordingly
|
|
|
|
| |
Fixes #50
|
|
|
|
|
|
|
|
| |
was set before.
That way, you don't always have to keep the parent commit uptodate when changing the
repo, which can lead to errors which are hard to debug and make no sense to the user,
who previously never set parent_commit (yet it matters thanks to the cache).
|
|
|
|
|
|
|
|
|
|
|
|
| |
default.
Previously, the implementation would gladly reset new commits in submodules,
and/or reset a dirty working tree.
Now the new force_reset/force flag has to be specified explicitly to get back
to the old behaviour.
All submodule tests except for one are working.
|
|
|
|
|
|
| |
path
Fixes #238
|
|
|
|
|
|
| |
A test verifies it's truly working.
Related to #238
|
|
|
|
|
|
|
| |
Improved a test to assure multiple update(init=False|True) calls don't
throw.
Fixes #93
|
|
|
|
|
|
|
|
| |
After all, it was easier than expected. It seems that previous assertions
the test made should have never been true to begin with. Thus we might
have improved the test thanks to our improved implementation.
Fixes #233
|
|
|
|
|
|
| |
This also means that now we seem to be able to properly handle .git files in submodules
Related to #233
|
|
|
|
|
| |
The root-submodule test is still failing though, this time even earlier
than before
|
|
|
|
| |
A simple test verifies this at least.
|
|
|
|
|
| |
However, a simple test-case still fails for reasons not yet understood.
There is more to be fixed here - .remove() still fails.
|
|
|
|
|
|
|
| |
There is some more work to do, as renames and updates still have to be
adjusted accordinlgy.
Relates #233
|
|
|
|
|
|
| |
It actually revealed a bug in the implementation of Submodule.add,
which just showed in python 3 for the wrong reasons. Thankfully,
failing tests after all allowed to get this issue fixed ... .
|
|
|
|
|
|
|
|
|
|
| |
string.
Previously, it would say it can handle absolute module paths, but didn't
actually do so.
A test-case was improved to check for this case.
Fixes #161
|
|
|
|
|
|
|
| |
Adjusted code to not check for .gitmodules existence anymore, we will
deal with it.
Fixes #117
|
|
|
|
|
|
| |
This is verified by the respective test.
Fixes #117
|
|
|
|
| |
Related to #74
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|