We got an error while switching on existent local branch
because git module can not find branch in function get_branches
if we have color.branch=always in git config.
One of the usual issue is that run_command return bytes,
so we have to adapt the string to either be bytes too,
or convert to string.
This result into that kind of traceback:
Traceback (most recent call last):
File \"/tmp/ansible_ej32yu2w/ansible_module_git.py\", line 1009, in <module>
main()
File \"/tmp/ansible_ej32yu2w/ansible_module_git.py\", line 873, in main
git_version_used = git_version(git_path, module)
File \"/tmp/ansible_ej32yu2w/ansible_module_git.py\", line 788, in git_version
rematch = re.search('git version (.*)$', out)
File \"/usr/lib64/python3.5/re.py\", line 173, in search
return _compile(pattern, flags).search(string)
TypeError: cannot use a string pattern on a bytes-like object
Another issue is filter being a object instead of a list.
* make HEAD parsing more robust
* Fail the module for any splitter errors
* fix combining depth and version on filepath urls by prepending file://
Addresses #907
* Made some changes to determine branch name more reliable (it may contain slashes now).
* Determination of branch name more reliable, as per comment on PR #907
* Git: Determine if remote URL is being changed
Ansible reported there were no changes when only the remote URL for a
repo was changed. This properly tracks and reports when the remote URL
for a repo changes.
Fixes#4006
* Fix handling of local repo paths
* Git: Use newer method for fetching remote URL
* Git: use ls-remote to fetch remote URL
Using ls-remote to fetch remote URL is supported in earlier versions
of Git compared to using remote command.
* Maintain previous behavior for older Git versions
Previously whether or not the remote URL changed was not factored
into command's changed status. Git versions prior to 1.7.5 lack the
functionality used for fetching a repo's remote URL so these versions
will update the remote URL without affecting the changed status.
* Add diffmode support to git module
This patch adds missing diffmode support to the git module.
* Remodel get_diff() and calls to it
As proposed by @abadger
* Ensure we fetch the required object before performing a diff
Also we handle the return code ourselves, so don't leave this up to run_command().
* remove unused variables
* fetch branch name instead of HEAD
fix#3782, which was introduced by f1bacc1d3f
* disable git depth option for old git versions
fixes#3782
git support for `--depth` did not fully work in old git versions (before 1.8.2)
fall back to full clones/fetches on those versions
* raise required git version to 1.9.1 for depth option
* use correct depth argument in switch_version
When `version` is not specified, it defaults to "HEAD". "HEAD" is not a
remote tag, and it's not listed in the output of get_branches(), so we'd
keep repo_updated at the default value (None) and then return early with
changed=True in --check mode, even when before == after.
Fixes#3024.
* remove unused variables
* fetch branch name instead of HEAD
fix#3782, which was introduced by f1bacc1d3f
* disable git depth option for old git versions
fixes#3782
git support for `--depth` did not fully work in old git versions (before 1.8.2)
fall back to full clones/fetches on those versions
* fix git switch branches in combination with depth
* the old implementation is correct, but relies on git working correctly
(as only newer versions do)
* with some older git version (e.g. 1.8.3), git fetch remote branch does
not work, if the branch does not yet exist locally
* this patch works around that without explicitly checking the git version
* future refactoring is needed to reduce the number of fetches to a
minimum; but this patch makes the code "correct"
* add git version requirements to doc
* replace set-branches with git 1.7.1 compatible version
From the git status doc:
--porcelain
Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable across Git versions and regardless of user configuration. See below for details.
User configuration can break the git module from working as expected.
* make git updates respect depth
until now `fetch` gets all tags and heads at full depth, this change
* uses `depth` argument for `fetch`
* only get the specified `version` in `fetch`
* fixes#14954
* treat combination of refspec and depth correctly
* be more conservative for non-depth fetch
The command `hg up -C` by default moves to the latest revision on the
current branch. The `discard` function was trying to update to a
different branch, in case it was provided, by passing a `-r REVISION`
argument. Not only is this not the intended effect of the `discard`
function, but this also could update to a different branch that hasn't
been pulled yet, which is how we were experiencing trouble.
Instead, we unconditionally do `hg up -C -r .` to "update" to the
current revision (i.e. to "."), while `-C/--clean`ing the current
directory. This is similar to `hg revert --all`, except that it also
undoes the merge state of the working directory, in case there was
any.
Detached head detection seems to have broken somewhere a long the way
because git decided to change how that situation looks when doing a 'git
branch -a' which is performed by get_branches().
This is how git 1.7.1 displays this situation (which works):
shell> git branch -a
* (no branch)
master
This is the output from git 1.8.3.1 (which does not work):
shell> git branch -a
* (detached from e132711)
master
It looks like this same wording is used in the most recent version of
git (2.6.1 as of writing this).
to support updates in Subfolders with Subversion > 1.8
Fix: Ignoring svn:externals on local Modification Check.
Add: Added Argument switch to alow skipping the svn switch call.
Anton Onufriev