| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
+ Ignore "empty" GIT_DIR vars. + Improve documentation on the constructor `path` parameter.
+ Expansion of paths also `osp.normalize()` them. + Make Repo-fields --> class-fields to avoid initializations on construct. + Explain and rename `git.repo.fun.find_git_dir()` is for submodules (`find_submodule_git_dir()`).
Current coverage is 94.36% (diff: 96.77%)@@ master #537 diff @@
==========================================
Files 63 63
Lines 9885 9892 +7
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 9326 9335 +9
+ Misses 559 557 -2
Partials 0 0
|
Sorry, something went wrong.
Conflicts: git/repo/base.py git/repo/fun.py git/test/test_submodule.py
| repo = Repo("$REPOSITORIES/Development/git-python.git") | ||
|
|
||
| if `None, current-directory is used. | ||
| The :envvar:`GIT_DIR` if set and not empty takes precendance over this parameter. |
There was a problem hiding this comment.
The environment variable taking precedence over the specified path seems error prone and undesirable. For instance, with GIT_DIR set, you can no longer do something like this:
repo_1 = git.Repo('/path/to/repo1')
repo_2 = git.Repo('/path/to/repo2')
I think GIT_DIR as a fallback makes sense (if path is None for instance). However, is there any reason to prefer it if an explicit path is provided?
Sorry, something went wrong.
There was a problem hiding this comment.
Discussion moved to original issue #535
Sorry, something went wrong.
FIX gitpython-developers#535 according to Byron's comment: gitpython-developers#535 (comment)
| Back | FazBrowse Home | New Git URL |
Minor repo-code and doc correcions.
construct.
(find_submodule_git_dir()).