# Looping over directories instead of files ?

**URL:** <https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293>\
**Category:** Ansible Project\
**Created:** [January 20, 2016, 4:51pm UTC](https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293 "2016-01-20T16:51:25Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Christophe\_Meessen](https://avatars.discourse-cdn.com/v4/letter/c/b2d939/32.png) [@Christophe\_Meessen](https://forum.ansible.com/u/Christophe_Meessen)\
**Post date:** [January 20, 2016, 4:51pm UTC](https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293/1 "2016-01-20T16:51:25Z")

</div>

I have a set of bare git directories stored as /home/git/XXX.git.

I would like to synchronize all the XXX.git directories with a remote server using ansible.  
But this is apparently not possible.

In my gitsrv role’s main.yml I have defined the following task:

- debug: msg=“src=‘{{item }}’”  
with\_fileglob:

- /home/git/\*.git  
tags: test

- name: Restore repositories  
synchronize: src=“{{ item }}” mode=push dest=“/home/git”  
with\_fileglob:

- /home/git/\*.git  
tags: restore

Both command do nothing because the blob set contains no file. It contains only directories and and with\_fileblob iterates only on files.

How could I synchronize the XXX.git directories with the remote server ?

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [January 20, 2016, 6:31pm UTC](https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293/2 "2016-01-20T18:31:04Z")

</div>

with\_pipe: find /home/git/\*.git -type d

---

<div class="post-metadata">

**Author:** ![Christophe\_Meessen](https://avatars.discourse-cdn.com/v4/letter/c/b2d939/32.png) [@Christophe\_Meessen](https://forum.ansible.com/u/Christophe_Meessen)\
**Post date:** [January 21, 2016, 10:24am UTC](https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293/3 "2016-01-21T10:24:10Z")

</div>

Thank you very much Brian. This was incredibly useful.

I had to do a small change to your suggested command otherwise it lists all the directories found recursively. I added the maxdepth option.  
This is for people looking later for the answer:

with\_pipe: find /home/git/\*.git -type d -maxdepth 0

---

<div class="post-metadata">

**Author:** ![Christophe\_Meessen](https://avatars.discourse-cdn.com/v4/letter/c/b2d939/32.png) [@Christophe\_Meessen](https://forum.ansible.com/u/Christophe_Meessen)\
**Post date:** [January 21, 2016, 10:54am UTC](https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293/4 "2016-01-21T10:54:58Z")

</div>

In fact it is still not right. The correct loop instruction is

with\_lines: find /home/git/\*.git -type d -maxdepth 0

This will make one iteration per command output line and assign it to item.

---

<div class="post-metadata">

**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\
**Post date:** [January 21, 2016, 1:49pm UTC](https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293/5 "2016-01-21T13:49:29Z")

</div>

if you only want the .gits:

with\_lines: find /home/git/ -name '\*.git' -type d -maxdepth 0

---

<div class="post-metadata">

**Author:** ![Christophe\_Meessen](https://avatars.discourse-cdn.com/v4/letter/c/b2d939/32.png) [@Christophe\_Meessen](https://forum.ansible.com/u/Christophe_Meessen)\
**Post date:** [January 21, 2016, 2:19pm UTC](https://forum.ansible.com/t/looping-over-directories-instead-of-files/20293/6 "2016-01-21T14:19:13Z")

</div>

Yes I only want the .git. Indeed your way to invoke find is more correct. However it still need a change to work on my Ubuntu computer. This one worked.

find /home/git/ -maxdepth 1 -name “\*.git” -type d

The maxdepth option should be moved to front and its value should be 1. Your way to invoke find is indeed better than mine