gitlabber doesn't delete local directory corresponded to deleted/moved repo on gitlab?

[dakoner]

Describe the bug A clear and concise description of what the bug is.

I'm not sure if this is a bug or not, but I noticed that if you gitlabber sync a GitLab group, and then delete a repo in the GitLab UI, re-running sync doesn't delete the local directory.

To Reproduce

1. Include the full command line with all arguments and the output in verbose (-v) mode $ gitlabber -t token -u URL ~/GitlabRoot

   delete a repo in the Gitlab UI

   $ gitlabber -t token -u URL ~/GitlabRoot

Expected behavior A clear and concise description of what you expected to happen.

I expected gitlabber to delete a synced repo that was deleted in GitLab.

Versions (please complete the following information):

• none of these shoudl matter but it was an Ubuntu VM running $ gitlabber --version 1.1.9

Additional context Add any other context about the problem here.

I don't know if this is considered a bug. Personally, I believe that if you have a sync tool and delete something upstream, default behavior should be to not delete the downstream copy, unless the user specifies a flag. For example, rsync operates this way.

[ezbz]

@dakoner the known limitations states this very clearly:

Project Renaming: Gitlabber doesn't maintain local state and will not rename local projects when they are renamed on the server and it will clone them again under their new name.

[dakoner]

That's a different limitation- rename. I asked about delete. You could update the documentation to say that explicitly; it was not obvious to me.

That comment also doesn't make sense to me, as gitlabber does maintain local state: the files it creates when cloning are that state. But I understand what your policy intent is and won't ask for gitlabber to be improved further.

[ezbz]

@dakoner Regarding renames/deletes it was a design choice early on to always read and replicate the project and group state from the server and not maintain local state. Gitlabber is a cli tool not an application, maintaining local state to track down server changes is a non trivial feat and not suitable for a CLI tool, there is no other way to get notified by the server when a project gets moved, deleted or renamed.

Regarding the local state you mentioned that state is maintained by git (not gitlab or gitlabber) and it is git state not gitlab api or project/group structure and lifecycle state so it's not relevant for moves, renames and deletes. You are right about the docs not being clear enough I will fix them

You are more than welcome to suggest additional features to gitlabber, if you want to make a different tool and make other design choices you are also welcome to that as well.

[ezbz]

Fixed in https://github.com/ezbz/gitlabber/commit/8e27de59a28513592eb1d0b9cd291837afc784d2

[dakoner]

Thanks for the clarified documents. I've adopted gitlabber and continue to use it without this feature.