# git module often marked as changed even when nothing changed

**URL:** <https://forum.ansible.com/t/git-module-often-marked-as-changed-even-when-nothing-changed/31555>\
**Category:** Ansible Project\
**Created:** [October 28, 2019, 7:46pm UTC](https://forum.ansible.com/t/git-module-often-marked-as-changed-even-when-nothing-changed/31555 "2019-10-28T19:46:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![MartinBBG](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@MartinBBG](https://forum.ansible.com/u/MartinBBG)\
**Post date:** [October 28, 2019, 7:46pm UTC](https://forum.ansible.com/t/git-module-often-marked-as-changed-even-when-nothing-changed/31555/1 "2019-10-28T19:46:59Z")

</div>

Using ansible 2.6

In our playbook, we are using the git module to checkout a specific repo. Most of the time, the playbook reports this as changed even though the repo has not changed. Sometimes it does properly report as not changed.

Here is the git module parameters:

- name: checkout our repo  
git:  
repo: “git@{{ serverurl }}:repo.git”  
dest: /opt/repofolder  
key\_file: /path/.ssh/sshkey  
ssh\_opts: “-o StrictHostKeyChecking=no”

accept\_hostkey: True  
update: yes

become\_user: localuser

When it reports as changed, it returns:

“after”: “f35210a1d1d008e5a7abc328733cab87c06589a6”,  
“before”: “f35210a1d1d008e5a7abc328733cab87c06589a6”,  
“changed”: true,

“remote\_url\_changed”: true

I’ve duplicated the directory and compared the entire directory. Some folders have a newer modified date. But no files were changed, with one exception, the file /opt/repofolder/.git/logs/HEAD has this added line:

f35210a1d1d008e5a7abc328733cab87c06589a6 f35210a1d1d008e5a7abc328733cab87c06589a6 localuser [localuser@computername.com](mailto:localuser@computername.com) 1572275580 +0000 checkout: moving from master to master

That line gets added even when ansible reports no change. And also, we use these same settings in other playbooks for other repos and those correctly only report as changed when changed.

Any idea why this is happening?

Thanks.

---

<div class="post-metadata">

**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\
**Post date:** [October 28, 2019, 8:05pm UTC](https://forum.ansible.com/t/git-module-often-marked-as-changed-even-when-nothing-changed/31555/2 "2019-10-28T20:05:11Z")

</div>

According to the return, it states:

“remote\_url\_changed”: true

This means that the URL for the remote is different as compared between the `repo` argument for the `git` module, and the value specified in `.git/config` within that repo.

You can compare what is in `.git/config` via the command ansible uses: `git ls-remote --get-url origin` from within `/opt/repofolder`

Past that, you would likely need additional debugging, following the code of the git module to determine why it’s not the same value.

---

<div class="post-metadata">

**Author:** ![MartinBBG](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@MartinBBG](https://forum.ansible.com/u/MartinBBG)\
**Post date:** [October 28, 2019, 8:47pm UTC](https://forum.ansible.com/t/git-module-often-marked-as-changed-even-when-nothing-changed/31555/3 "2019-10-28T20:47:07Z")

</div>

Thanks for the reply Matt.

You were right that the git url was different. I changed the url in .git/config and now the output of ‘git ls-remote --get-url origin’ matches what is in the ansible repo parameter. However, it is still reporting as Changed most of the time that I run the playbook. And remote\_url\_changed is still returning true on those runs.

Any idea how I could troubleshoot this further?

---

<div class="post-metadata">

**Author:** ![MartinBBG](https://avatars.discourse-cdn.com/v4/letter/m/a8b319/32.png) [@MartinBBG](https://forum.ansible.com/u/MartinBBG)\
**Post date:** [October 31, 2019, 4:01pm UTC](https://forum.ansible.com/t/git-module-often-marked-as-changed-even-when-nothing-changed/31555/4 "2019-10-31T16:01:52Z")

</div>

Actually, it looks like you were right Matt. We had some other external process that was changing that url back.