There is a subtle bug in how the git module currently works. If the
version you request is a tag name, and you've already got the repo
cloned, and the tag name is a new tag, but refers to the already checked
out working copy, the git module would exit early without change. This
is bad as it means the new tag ref was not fetched and could not be used
in later tasks.
This change will check if the version is a remote tag, and if the tag
doesn't exist locally. If that is true, it'll do a fetch.
The activity could still be seen as not a change, because the working
copy won't be updated, if the new tag refers to the already checked out
copy, but that's not different than before and can be fixed as a more
comprehensive overhaul of tracking change in the git module.
There is a bug in the `hg` module where if a `tag` is used it won't
properly be able to update to it.
This problem is exhibited on repository where a tag is moved from an
older commit to a newer commit.
This adds two parameters to the git module:
bare (boolean)
Indicates this is to be a bare repositori
reference (string)
Indicates the path or url to the reference repo.
Check out the "--reference" option in the "git clone"
man page
Added appropriate tests.
The return values from check mode and non-check mode should match in all cases,
except when a SHA-1 hash is used as version, as there is no way to check if it
is a valid hash using `git ls-remote`.
Also, to accomodate this change, the force flag for the reset function has been
removed so that we can do the checking in main.
For issue #3372, apply consistent parameter aliases to source_control
modules. For hg, add name and version and add to documentation string.
For subversion, add version and document version and name aliases in
documentation string.
"UnboundLocalError: local variable 'branch' referenced before assignment" is
raised in git, line 282, in switch_version.
Exception is raised when version is not branch and version checkout fails.
E.g. when version is nonexistant commit.
Git is unable to checkout the specified `version` when the repository is
cloned with a reduced history (`depth`). However, if the repository is
already cloned, subsequent git module calls will update the repository
(default update=True), then properly checkout the specified `version`.
To allow the initial call to properly clone the specified `version`, at
the specified `depth`, this patch adds the `--branch` parameter when
cloning the repository.
This does two things:
* add --recursive option to git clone command in clone(). This will
initialize all submodules when cloning a remote repository.
* Add submodule_update() and call that from fetch(). submodule_update()
calls two git commands iff the file .gitmodules exists in the
repository:
* 'git submodule sync' - synchronizes the submodules' remote URL
configuration setting to the value in .gitmodules.
* 'git submodule update --init --recursive' - initialize and update
registered submodules to the commit specified in the index of the
containing repository.
If a repository was cloned without --recursive, submodule_update() will
ensure that the submodules are initialized and updated.
Migrated all examples: in DOCUMENTATION=''' string to standalone EXAMPLES=''' string
Added deprecation warning to moduledev.rst and remove deprecated example from it
Fixed up a few typos and uppercased some acronyms.
add consistency to how EXAMPLES are formatted
This will allow just making sure the repo exists w/out actually making
any chnages to it. Useful if you're going to run a play repeatedly
against a host that might have active development going on in the
repository (think initial bootstrap of a developers system, and
continued playbook runs to work on other projects).
