It would be neat if github could store all its data in git, similar to fossil scm. But I suppose microsoft would not want to lose lockin.
It would be neat if github could store all its data in git, similar to fossil scm. But I suppose microsoft would not want to lose lockin.
Yes, that would be very nice - it is unfortunate that you have to make API calls (over http) to get things like issues ...
I think you can get the wiki with plain old 'git' ? I forget ...
This is correct. The wiki for a repo is accessible as a separate repository named with a suffix of “.wiki”.
So if user foo has a repo bar with an associated wiki, and the repo URL is https://github.com/foo/bar then you can clone the repo and the wiki respectively over SSH by:
git clone git@github.com:foo/bar.git
and git clone git@github.com:foo/bar.wiki.git
I wish they’d do the same for all other repository meta data including issues, repository description, etcThat is, you need API calls to get things like issues.
Is there a single tool that will handle downloading (and the associated API calls) from all of the major providers ? Or is each API tool specifically for either github or gitlab or sr.ht or whatever ?
What I am wondering is are there any tools that use these APIs that have built-in support for multiple provider APIs ? Or does every tool that (helps you manage or download issues, etc.) just built for a particular provider ?
Thanks.
Most of the other such tools I've seen barely have the resources to import/export a single such API. git-issue only has Github import it looks like. https://github.com/dspinellis/git-issue
There's perceval which is designed to be a generic archival tool and supports lots of APIs, but only dumps them to source-specific formats and would still need a lot of work if you tried to use issues from different APIs together: https://github.com/chaoss/grimoirelab-perceval
I think the article talks about the "What" part of the problem, but the actual code is much more interesting in the "How" sense.
Like the git-ref stuff makes sense as you read the code
https://github.com/ligurio/git-test/blob/master/bin/git-test...
There was a similar set of additions to svn in the past with "svn propedit" in the workflows which I used in a previous workplace.
It was not pretty, because it was like embedding JIRA into svn - but it meant machines could flip state to state with commits during build+test and restart from that point without an independent DB to track the "current state" & people with commit access could nudge a stuck build out without losing "who did what".