support for local repos

[Dieterbe]

beginnings of support for #135
i made some progress on this months ago, but ran out of steam.
publishing what i have because i hope to find other collaborators.

to recap, the goal is:

1. scan local working copies (you and i probably have many stale git repos checked out on our laptops taking up valuable disk space)
2. determine which are safe to delete (if they have no commits that were not merged to a remote, nothing in stash or index, and no untracked files)
3. use the term UI to make it visually clear which are safe to delete and make it easy for user to confirm deletions. this same concept would also expand to fork-cleaner's current approach for scanning github forks.

[ccoVeille]

@Dieterbe I saw your issue, then I was surprised you made a WIP PR

How far were you from having everything all set?

[Dieterbe]

@ccoVeille from what i recall there was quite some work left to do.

[ccoVeille]

Thanks for replying.

OK, is there a chance you would work on this again?

[Dieterbe]

Not any time soon 😞

[ccoVeille]

Not any time soon 😞

Thanks for replying me. It's always good to have a status.

[Dieterbe]

i found some time to work on this again.
i think it's coming together now. needs a bit more polish. haven't implemented deleting yet, but if you want to have a look, now would be a good time.

included is a shell script which sets up various git repos for testing. the directories are named to describe the "case", making it easier to see whether fork-cleaner interprets each case correctly (seems like it does).

you can then run fork-cleaner -t <your-token> --path /tmp/tmp.v1gqW8YG4i and see something like this:

@caarlos0 what do you think? :-)

[Dieterbe]

seems to work pretty well now. i've deleted about 30 stale repos in my code directory, so far.
the main thing is that it's slow. maybe i'll add some concurrent processing (doing api calls in parrallel)
i also notice that in the original code, after a reposDeletedMsg message, we re-scan all the repos, so i've implemented it the same way in my code. However, this seems unnessary. we already update the list to take out the repos that we're deleting, so no rescanning should be needed.

[Dieterbe]

seems the CI failures are unrelated to my work 🤔

[Dieterbe]

One might ask: why is this a PR for this repo, and not a standalone tool, in a separate repo?
It could be seperated, because in fact there is barely any code overlap.
But the overlap is in the audience, and in the UX.
I suspect people interested in the current functionality (cleaning up github forks), might also be interested in cleaning up code repos on their hard drives, and vice versa.
I also think it would be nice to have a consistent UX across both modes (in the UI, command line args, etc) and keeping them in the same repo helps with this.

So I rather collaborate on 1 tool rather than make my own separate tool or fork