Update to upstream version '0.0.11'
with Debian dir a108f7c4dbea9105ec578d819bf6d8c357e6501c

Update to upstream version '0.0.10'
with Debian dir f15cce5a06b2f6487de49dd32123ca52507d8d3d

This permits to reuse the same logic for different clients (loader-dir,
loader-tar, loader-svn)

(Tests were lost)

This actually is supposed to replace
walk_and_compute_sha1_from_directory.
The data structure used here is better at handling updates.

(Code that actually got lost and rewritten - Tests are definitely lost though)

Keep the old api (since i don't measure the impacts on other modules yet).

+ Improve docstring

(Code that actually got lost and rewritten)

Update to upstream version '0.0.9'
with Debian dir 43fe71cfe2540cb75fc3848e25e7d4d8e65cdee6

Update to upstream version '0.0.8'
with Debian dir 2ebe42f6f56469dedd2e7bb2c7b326de8bf6bfa3

Combination of:
- validation on files
- ignore empty folder

Update to upstream version '0.0.7'
with Debian dir 7d9ad79fa5b214792dc0896603959278f846f2d0

In some corner case, the changed paths can reference a previous ignored
folder (thus not existing in the data structure)

Update to upstream version '0.0.6'
with Debian dir e608e904098cbb721f8ddd00592aaf3038b3c401

The empty folder was not previously in the objects structure.
So we need to add it as child of its parent for the update.

Update to upstream version '0.0.5'
with Debian dir a119724edea7671ff7294ad188ced9b2bb63c0c0

Enforce convention on directory name without trailing /.
At the moment, the `git.walk_and_compute_sha1_from_directory` injected
the rootdir with a possible trailing / (input from client).

Since we compute it anyway, better return it along with the result

Decrease the number of paths to compute to 1 common ancestor (if any):
- Scan only that directory and rehash with new results (data changed)
- Update the resulting objects with those new hashes.
- Update from that directory to the rootdir the existing hashes computation