You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
By using ghorg I clone a lot of repositories, more because I can than because I need all of them. Due to the amount of repositories it becomes unfeasible to track which of these were just cloned and on which I really worked. If I wanted to free some disk space or adapt to a restructuring, I would have to inspect each and every repository to see whether it has unpublished information, either as commit on the main branch or as additional branch.
Describe the solution you'd like
I would like to suggest a feature that ghorg can remove repositories where the remote repository still exists and each branch and each commit from local are available in remote.
To clarify with the help of some scenarios:
ghorg clone, ghorg prune -> all cloned repositories would be removed.
ghorg clone, git commit in one of the repositories, ghorg prune -> the one repository would remain
ghorg clone, git commit and git push in one of the repositories, ghorg prune -> all repositories would be pruned
Describe alternatives you've considered
I tried to come up with a Bash script, but it is error prone and complex. Considering that ghorg already knows how manage multiple repositories, it seems like a natural fit.
The text was updated successfully, but these errors were encountered:
There are options for filtering down the repos you clone. Also creating a ghorgignore file sounds like it could be a good option for your use case.
Maybe a new command like ghorg clean could remove any repo that a specified list of users does not have a commit in. Or a new flag --has-commits=username1,username2 would only clone repos where those users have commits/contributions.
I think you are thinking the problem from the wrong end. My request is not to get new flags to exclude repositories from being cloned. I indeed want to clone all available repositories for good reasons.
First, it is just more convenient and structured to simple get the entire organisation than to clone a bunch of repositories manually. Second, I often want to bulk apply changes to several of them without knowing beforehand which repositories will be affected. Think of replacing a Docker image or updating some library. Third, I find the Unix tools more convenient and productive that Gitlab's built in search.
So, I indeed want to clone all repositories available to me. Ghorg does a great job in doing so. Thank you very much here.
However, after some time I might want to learn where I have pending work to finish it up. Maybe I want to free some space. In these cases, I would like to get ghorg's support.
Is your feature request related to a problem? Please describe.
By using
ghorg
I clone a lot of repositories, more because I can than because I need all of them. Due to the amount of repositories it becomes unfeasible to track which of these were just cloned and on which I really worked. If I wanted to free some disk space or adapt to a restructuring, I would have to inspect each and every repository to see whether it has unpublished information, either as commit on the main branch or as additional branch.Describe the solution you'd like
I would like to suggest a feature that
ghorg
can remove repositories where the remote repository still exists and each branch and each commit fromlocal
are available inremote
.To clarify with the help of some scenarios:
ghorg clone
,ghorg prune
-> all cloned repositories would be removed.ghorg clone
,git commit
in one of the repositories,ghorg prune
-> the one repository would remainghorg clone
,git commit
andgit push
in one of the repositories,ghorg prune
-> all repositories would be prunedDescribe alternatives you've considered
I tried to come up with a Bash script, but it is error prone and complex. Considering that
ghorg
already knows how manage multiple repositories, it seems like a natural fit.The text was updated successfully, but these errors were encountered: