4 ms·

They say that git data (repos and wikis) are not affected... well ... if they would have had their PRs and Issues in git repositories, too... Disclaimer: Worke

They say that git data (repos and wikis) are not affected... well ... if they would have had their PRs and Issues in git repositories, too... Disclaimer: Worked on a POC for exactly this last semester and going to publish my results in the next few weeks.

talex5 10y ago
Yes, doing this would make it easier to use services like GitHub. For example, DataKit's GitHub bridge service uses webhooks to track changes in GitHub metadata (e.g. the status of branches, tags and PRs) and stores the state in another Git branch. The DataKitCI monitors this branch to know when to build things (and writes the status back there): https://github.com/docker/datakit/tree/master/ci https://github.com/docker/datakit/tree/master/ci Would be simpler if GitHub offered this data in Git format directly.
jschulenklopper 10y ago
> if they would have had their PRs and Issues in git repositories, too Well, perhaps a git repository isn't the right persistency structure for non-code items like issues and pull requests. That a git repository is a good structure for document-like entities (like code files) and tracking changes/versions, doesn't mean that it's a good choice for highly-relational or highly-dynamic objects.
- musicmatze 10y ago
  Well, from what we've experienced during the implementation and while using our tool, it works _really_ well!
procrastitron 10y ago
GitLab has an open issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/4084 https://gitlab.com/gitlab-org/gitlab-ce/issues/4084) to use git-appraise (https://github.com/google/git-appraise https://github.com/google/git-appraise) for storing pull requests in the repository.
- musicmatze 10y ago
  I just checked git-appraise and while it looks rather mature, it uses (as far as I can see by now) an approach which is not that nice if you have multiple public remotes. Also, as far as I can see, each submitter must be able to push to that remote - please correct me if I'm wrong. We have a different approach for this, which is more powerful (talking about how the data is stored). Of course, our tool is not mature yet. Maybe gitlab can learn from what we've researched...

talex5 10y ago

Yes, doing this would make it easier to use services like GitHub. For example, DataKit's GitHub bridge service uses webhooks to track changes in GitHub metadata (e.g. the status of branches, tags and PRs) and stores the state in another Git branch. The DataKitCI monitors this branch to know when to build things (and writes the status back there): https://github.com/docker/datakit/tree/master/ci https://github.com/docker/datakit/tree/master/ci Would be simpler if GitHub offered this data in Git format directly.

jschulenklopper 10y ago

> if they would have had their PRs and Issues in git repositories, too Well, perhaps a git repository isn't the right persistency structure for non-code items like issues and pull requests. That a git repository is a good structure for document-like entities (like code files) and tracking changes/versions, doesn't mean that it's a good choice for highly-relational or highly-dynamic objects.

musicmatze 10y ago
Well, from what we've experienced during the implementation and while using our tool, it works _really_ well!

procrastitron 10y ago

GitLab has an open issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/4084 https://gitlab.com/gitlab-org/gitlab-ce/issues/4084) to use git-appraise (https://github.com/google/git-appraise https://github.com/google/git-appraise) for storing pull requests in the repository.

musicmatze 10y ago
I just checked git-appraise and while it looks rather mature, it uses (as far as I can see by now) an approach which is not that nice if you have multiple public remotes. Also, as far as I can see, each submitter must be able to push to that remote - please correct me if I'm wrong. We have a different approach for this, which is more powerful (talking about how the data is stored). Of course, our tool is not mature yet. Maybe gitlab can learn from what we've researched...