7 ms·

But that’s not what parent meant. Those things should be embedded in the git repository itself, in some kind of structure below the .git/ directory. That would

by 9dev 3y ago

But that’s not what parent meant. Those things should be embedded in the git repository itself, in some kind of structure below the .git/ directory. That would indeed make the entire OSS ecosystem more resilient. We don’t need a myriad of incompatible git web GUIs, but a standard way of storing project management metadata alongside version control data. GitHub, Gitea, Gitlab, and this project could all store their data in there instead of proprietary databases, making it easy to migrate projects.

gsaslis 3y ago
Yes, this is how radicle stores this data. ; ) https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82/tree/0003-storage-layout.md https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...
- gsaslis 3y ago
  https://docs.radicle.xyz/guides/protocol https://docs.radicle.xyz/guides/protocol is probably a better resource (but this guide is still Work In Progress)
  - est 3y ago
    > Radicle’s predefined COB types are stored under the refs/cobs hierarchy. These are associated with unique namespaces, such as xyz.radicle.issue and xyz.radicle.patch, to prevent naming collisions. This looks like an interesting approach. I have question, to avoid copy a large .git project, we have partial cloning and cloning depth. If `cobs` grows too large, how can we partially clone it? Like select issues by time range?
    - sebastinez 3y ago
      The COB types are located in the Stored Copy, you would still be able to partial clone the working copy repo without the issues and patches, with your current git commands. There is a better explainer here: https://docs.radicle.xyz/guides/protocol#storage-layout https://docs.radicle.xyz/guides/protocol#storage-layout
- account42 3y ago
  > a standard way of storing project management metadata alongside version control data Emphasis mine. Doesn't seem to be it seening as this is yet another home grown issue storage.
  - 9dev 3y ago
    Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/ https://xkcd.com/927/
    - avgcorrection 3y ago
      And Fossil is an entirely different VCS. What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)
      - 9dev 3y ago
        Yes! That's exactly what I would like to see - come together as a working group, create a PR on git itself, and implement standard support for issues, PRs, discussions, projects, votings, project websites, what-have-you. The community will take it from there. The alternative to that would be the git project itself coming up with an implementation. They have reasonable experience working with the Kernel, and the creation of git itself seems to have worked reasonably well -- although I'm not sure I would want to use something Linus considers ergonomic :)
        account42 3y ago
        I would have like to have seen what kind of issue resolution labels old Linus would have come up with. Resolved: YOU GIT has a nice ring to it.
        avgcorrection 3y ago
        Ok. That could work if you found a group of people who are interested in such an all-in-one package. Gitlab is apparently working on a sort of cross-forge protocol (probably motivated by connecting Gitlab instances) and it seems that some Gitlab employees are working full time on the Git project. So those are candidates. You probably need a group which both have recognition within the project and are active enough to drive such a project forward without it fizzling out. Without such a group you might just send a few emails to mailing list, get shrugs about how that plan “looks good” with little real interest, and then have to discuss this big plan in every future patch series that incrementally builds such a thing into Git itself. Mostly why such code should be incorporated and how it will pay off when it’s all ready. The Git tool itself—and the project by extension—is per now very unopinioated about whole-project solutions like this. The workflow that they themselves use is very loosely coupled and pretty much needs bespoke scripting by individual contributors, which I guess is telling in itself.
zlatan_todoric 3y ago
Radicle does store such data in git - issues, patches (PRs) etc. Also, the entire project (protocol, cli, web ui etc) is fully open source.
Brian_K_White 3y ago
Nothing should be under .git/ except things owned by git (or at least allowed for in an explicit way like the hook scripts). You would have to either add the features to git itself, or at least add to git the knowledge of and allowance for extra features like that. But not just toss non-git data in .git/ simply because the dir happens to exist.
- 9dev 3y ago
  > You would have to either add the features to git itself, That is exactly what I'm suggesting.
  - Brian_K_White 3y ago
    I don't think I would agree. Well it depends exactly what you imagine. There are probably an infinite and always growing and changing number of repo-adjacent things similar to the handful of added features that github currently tacks on to git. I think it doesn't make sense for git, already complicated enough, to try to do all of that other related stuff, however related. Maybe in fact git is already doing too much meaningful metadata work directly itself, and should instead try to switch it's current metadata into some kind of generic interface that other software could hook in to better? So rather than git managing, say, issues, git just manages data. Not merely a db, it would facilitate associating high level feature data like issues and ci and conversations with low level commit data. An issue tracker would just be one of many clients using the interface. git itself should probably not know very much about the data other than how it is associated to some commit. IE, the actual meaning of the data is either only in the consumer, or perhaps is some agreed standard that multiple consumers adhere to and understand, or perhaps comes with it's own schema definition like dtd or protobuf. Or all of the above, a paid product could have data only it understands, and other software could use standardized data, all stored in git at the same time. Multiple different consumers could use the same generic interface to their own data. Because these add-on related functions are probably not universal or done being invented. Tomorrow there will be 5 new things you want to attach to a repo besides what github provides today, and so without even knowing what they are, that's how I know it's wrong for git to provide the features itself. But managing the data without caring what the data is, that could totally be a new built in git function, where you give git itself one new function and interface, and an open-ended number of new feature-providing consumers all just use the same underlying git feature in whatever way they want. Other than that the only other new thing I think that might be right to add to git itself is a proper way to manage large binary assets.

by 9dev 3y ago

gsaslis 3y ago

Yes, this is how radicle stores this data. ; ) https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82/tree/0003-storage-layout.md https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...

gsaslis 3y ago
https://docs.radicle.xyz/guides/protocol https://docs.radicle.xyz/guides/protocol is probably a better resource (but this guide is still Work In Progress)
- est 3y ago
  > Radicle’s predefined COB types are stored under the refs/cobs hierarchy. These are associated with unique namespaces, such as xyz.radicle.issue and xyz.radicle.patch, to prevent naming collisions. This looks like an interesting approach. I have question, to avoid copy a large .git project, we have partial cloning and cloning depth. If `cobs` grows too large, how can we partially clone it? Like select issues by time range?
  - sebastinez 3y ago
    The COB types are located in the Stored Copy, you would still be able to partial clone the working copy repo without the issues and patches, with your current git commands. There is a better explainer here: https://docs.radicle.xyz/guides/protocol#storage-layout https://docs.radicle.xyz/guides/protocol#storage-layout
account42 3y ago
> a standard way of storing project management metadata alongside version control data Emphasis mine. Doesn't seem to be it seening as this is yet another home grown issue storage.
- 9dev 3y ago
  Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/ https://xkcd.com/927/
  - avgcorrection 3y ago
    And Fossil is an entirely different VCS. What’s the alternative? That at least N projects cooperate and agree on a common design before they do the implementation? (Then maybe someone can complain about design-by-committee.)
    - 9dev 3y ago
      Yes! That's exactly what I would like to see - come together as a working group, create a PR on git itself, and implement standard support for issues, PRs, discussions, projects, votings, project websites, what-have-you. The community will take it from there. The alternative to that would be the git project itself coming up with an implementation. They have reasonable experience working with the Kernel, and the creation of git itself seems to have worked reasonably well -- although I'm not sure I would want to use something Linus considers ergonomic :)
      - account42 3y ago
        I would have like to have seen what kind of issue resolution labels old Linus would have come up with. Resolved: YOU GIT has a nice ring to it.
      - avgcorrection 3y ago
        Ok. That could work if you found a group of people who are interested in such an all-in-one package. Gitlab is apparently working on a sort of cross-forge protocol (probably motivated by connecting Gitlab instances) and it seems that some Gitlab employees are working full time on the Git project. So those are candidates. You probably need a group which both have recognition within the project and are active enough to drive such a project forward without it fizzling out. Without such a group you might just send a few emails to mailing list, get shrugs about how that plan “looks good” with little real interest, and then have to discuss this big plan in every future patch series that incrementally builds such a thing into Git itself. Mostly why such code should be incorporated and how it will pay off when it’s all ready. The Git tool itself—and the project by extension—is per now very unopinioated about whole-project solutions like this. The workflow that they themselves use is very loosely coupled and pretty much needs bespoke scripting by individual contributors, which I guess is telling in itself.

zlatan_todoric 3y ago

Radicle does store such data in git - issues, patches (PRs) etc. Also, the entire project (protocol, cli, web ui etc) is fully open source.

Brian_K_White 3y ago

Nothing should be under .git/ except things owned by git (or at least allowed for in an explicit way like the hook scripts). You would have to either add the features to git itself, or at least add to git the knowledge of and allowance for extra features like that. But not just toss non-git data in .git/ simply because the dir happens to exist.

9dev 3y ago
> You would have to either add the features to git itself, That is exactly what I'm suggesting.
- Brian_K_White 3y ago
  I don't think I would agree. Well it depends exactly what you imagine. There are probably an infinite and always growing and changing number of repo-adjacent things similar to the handful of added features that github currently tacks on to git. I think it doesn't make sense for git, already complicated enough, to try to do all of that other related stuff, however related. Maybe in fact git is already doing too much meaningful metadata work directly itself, and should instead try to switch it's current metadata into some kind of generic interface that other software could hook in to better? So rather than git managing, say, issues, git just manages data. Not merely a db, it would facilitate associating high level feature data like issues and ci and conversations with low level commit data. An issue tracker would just be one of many clients using the interface. git itself should probably not know very much about the data other than how it is associated to some commit. IE, the actual meaning of the data is either only in the consumer, or perhaps is some agreed standard that multiple consumers adhere to and understand, or perhaps comes with it's own schema definition like dtd or protobuf. Or all of the above, a paid product could have data only it understands, and other software could use standardized data, all stored in git at the same time. Multiple different consumers could use the same generic interface to their own data. Because these add-on related functions are probably not universal or done being invented. Tomorrow there will be 5 new things you want to attach to a repo besides what github provides today, and so without even knowing what they are, that's how I know it's wrong for git to provide the features itself. But managing the data without caring what the data is, that could totally be a new built in git function, where you give git itself one new function and interface, and an open-ended number of new feature-providing consumers all just use the same underlying git feature in whatever way they want. Other than that the only other new thing I think that might be right to add to git itself is a proper way to manage large binary assets.