Not only is this a great idea but there's no reason this couldn't be an API layer over any number of underlying source control implementations (Git, Mercurial, Bazaar, TFVC, SVN, etc). Could open up all kinds of possibilities for CI/CD tooling and workflows as well.
The scope of GitPub is still under active definition, and it might end up not being specific to git only.
If you're a stakeholder of any service that could federate based on Mercurial, Bazaar… you're more than welcome to give your input to the working group.
For sure, is there already a proposal for federated merge requests? Or can you make those from the activity stream? That would by the minimal viable change as far as I can see.
First thing first: I would hope that "Git" would be removed from the GitPub name. I'm in favor of replacing Git in the process and having both a new client source control implementation and server API set (SourcePub?) that are designed with each other in mind, eases federation, and is both powerful and easier for new devs than Git (Hg managed this... not sure why a Git replacement can't do the same).
GitPub (or whatever it'll be named then) does not intend to replace git or any other VCS. Its stated goal is to enable federation between services such as GitHub, GitLab, Gogs, Gitea, Pagure… which happen to use git.
In other words, it means that if GitPub was adopted by these services, you could submit a merge request from Pagure to Gitlab, or star a GitHub project from your own Gitea instance, among many other things.
Well in this case why Github, GitLab, etc.. do not allow you to "star" a repo more than once?
I'm fine with stars not being significant, but it's still not good if a malicious actor can suddenly spoof hundreds of accounts and spam stars, comments and what-not.
Because that's a completely different interaction. You can still create another account and star it again.
Sure, your IP will be rate-limited (GH at least) if you script it and start hammering stars, but that's not because it wants to protect the integrity of the repo star count.
I really hope they stick with Git and produce something concrete rather than trying to shoehorn a diverse collection of version control models into the same API. The last thing you want is the sort of lowest common denominator solution that everyone agrees on but is otherwise useless.
Later, after the GitPub federation approach is proven, let another team take up the torch for AnyPub.
To me it seems like the real power of and differences between tools is apparent mostly in the context of offline history editing. Once you're making pull requests, nobody wants anything complex in the PR. Lowest common denominator - "here is a set of commits" might be fine.
The project might need to change name; it seems like it may be violating the Git trademark rules[1]:
> Portmanteaus ("GitFoo" or "FooGit") are out. Most of the cases run into this rule. For instance, we asked GitHub to not to use "DGit" to refer to their replicated Git solution, and they[1] rebranded. We also asked "GitTorrent" not to use that name based on this rule.
> The USPTO initially rejected our application as confusingly similar to
the existing trademark on GitHub, which was filed in 2008. While one
might imagine where the "Git" in GitHub comes from, by the time we
applied to the USPTO, both marks had been widely used in parallel for
years. So we worked out an agreement with GitHub which basically says
"we are mutually OK with the other trademark existing".
> (There was another delay caused by a competing application from a
proprietary version control company that wanted to re-brand portions of
their system as "GitFocused" (not the real name, but similar in spirit).
We argued our right to the name and refused to settle; they eventually
withdrew their application).
> So GitHub is essentially outside the scope of the trademark policy, due
to the history. We also decided to explicitly grandfather some major
projects that were using similar portmanteaus, but which had generally
been good citizens of the Git ecosystem (building on Git in a useful
way, not breaking compatibility). Those include GitLab, JGit, libgit2,
and some others. The reasoning was generally that it would be a big pain
for those projects, which have established their own brands, to have to
switch names. It's hard to hold them responsible for picking a name that
violated a policy that didn't yet exist.
wow... reading the git trademark policy now, it's... surprising:
> While the original idea was to prevent people from forking the software, breaking compatibility, and still calling it Git, the policy covers several other cases.
> One is that you can't imply successorship. So you also can't fork the software, call it "Git++", and then tell everybody your implementation is the next big thing.
This seems like a massive violation of the spirit of GPL... explicitly disallowing official endorsement is one thing (since that would be lying), but you shouldn't be able to stop someone going and doing their own thing and calling it git-something.
The GPL says nothing about branding though. The GPL is about user freedom, the ability to let the user improve (and share improved version of) the software.
In general, people tend to confuse copyright/patent with branding. The former is about using, while the later is about naming. You can totally make the next git-killer, and base it on git. What you cannot do is name it "GitSomething" (regardless of whether it uses git behind the scenes), as that would be a trademark violation.
I personally think the policy makes sense, but I also understand that there might be reasonable arguments either side. But framing it as an "anti-GPL" thing seems disingenuous to me.
> In general, people tend to confuse copyright/patent with branding
I understand how trademark laws work, I'm talking about why this policy is wrong and against how OSS projects work in general. The original purpose (as stated by the policy itself) was supposedly to protect confusing forks of the same name or prevent pseudo successors, but it goes way beyond this to attack anything with git in the name.
> For example, imagine a software project which is only tangentially related to Git. It might use Git as a side effect, or might just be "Git-like" in the sense of being a distributed system with chained hashes. Let's say as an example that it does backups. We'd prefer it not call itself GitBackups. We don't endorse it, and it's just using the name to imply association that isn't there. You can come up with similar hypotheticals: GitMail that stores mailing list archives in Git, or GitWiki that uses Git as a backing store.
They reason this issue as "endorsement"... yet it's so common to have an ecosystem around a popular piece of software where project names are a derivative of the name of the core software it builds upon, I doubt anyone ever got confused or even cared much about endorsement, instead I think enforcement of this policy will just make the relationship and purpose of software built for use with git more opaque to users.
That may be so, there's probably also a whole bunch of people out there who think that Bill Gates invented the computer, it doesn't matter... it's a fools errand to try to eradicate ignorance of outsiders at the cost of disregarding any relationship that is not official and "endorsed" as invalid, i'd go as far as saying it's toxic.
Endorsement is not the only valid relationship between pieces of software, and it's definitely not the most important one. As an example of how bad this can be, git asked gitTorrent to change it's name to remove "git" - how absurd is that, git's protocols are modular, they are intended to be extended, this adds a torrent type protocol to git, it's for git... what the fuck else would you call it:
This "policy" completely disregards this as a valid relationship... why does it have to be endorsed, no one cares, they care about names that clearly communicate their purpose. gitTorrent and a thousand other extensions to git probably aren't going to be as popular as git itself, they aren't going to have enough presence that naming them something completely unique and obscure is going to be useful to users.
[edit]
I just want to say (and then I'll stop ranting), as much as this policy obviously irritates me... I love git, and so was pretty disappointed to find this, it doesn't make me love git any less, but It makes me more wary of people who "manage" open source projects.
> I guess Richard Stallman violated the "spirit of the GPL" when he made MicroGnuEmacs change their name.
No, because he asked them to remove "GNU" and It is not part of or for GNU, does not use GPL and is not a fork (it uses a combination of public domain and BSD licenses)... if he asked them to remove "Emacs" from the name then this would be the same issue - but it's not.
I am not familiar with the details of that discussion but I doubt many people would argue against me when I say it's very likely RMS was against them using GNU in the name of public domain and BSD licensed software due to significant differences in implied licensing, this is completely different reasoning to git's where it disapproves of _any_ implied relationship that is _not_ endorsed.
Also note that the focus of my comment is explicitly on the details of the significant implications to related software that is _not_ a fork or clone.
I don't think it violates the GPL, as the GPL doesn't really care about names. You still have every right to fork git, but have to call it a different name. So if you call your fork "treengler" or whatever, you'd be fine. As far as I can see, you could also still say on your website "Treengler is a fork of Git, that adds/modifies/improves... it in the following way, ...".
To me that seems to be compatible with the text as well as the spirit of the GPL. I think a similar discussion came up in the Debian project with the Firefox trademark at some point. Debian is quite picky about what it means for software to be free, and they seem to be fine with derivatives not being allowed to modify Firefox without changing the name. (At least, I think that was the end status of this discussion.)
Not against the spirit of GPL or free software at all. Governing the use of language and branding to promote software freedom is core to the movement.
The steward of git defining what does and does not have the git nature is completely in line with this. You want your own take on git? Go ahead, you explicitly have the four freedoms to do so, but don't muddy the waters by calling it git if you don't represent the project.
> You want your own take on git? Go ahead, you explicitly have the four freedoms to do so, but don't muddy the waters by calling it git if you don't represent the project.
That was the original intent of the policy and not what I have issue with, but it goes much further than that, see my other comments for details.
Keeping this relevant: GitPub is not trying to replace git obviously.
The GPL exists to preserve the rights of downstream users. In doing so, it restricts the rights of downstream developers and distributors from restricting the rights of their users.
But we could go on and on back and forth about this. I just wanted to make sure the opposing view from yours is present in the thread near your claim.
That's essentially a historical accident. From the same email[1]:
> The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing".
> GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist.
There's also some further discussion about how it probably gives them an unfair advantage, but that's the policy they've chosen to persue regardless.
Thanks a lot. We're discussing on changing name. We will not use the name in our final release. Please allow us to temporary attach to the name until we have a new one.
That's a good point. This has been discussed as well for the renaming of Microsoft's GVFS.
GitPub is still very young, and it might end up supporting (D)VCS other than git, so absolutely nothing in it is definitive right now, not even the name.
They'll be in the same situation. It might be worth shooting them an email with a link to the official policy (https://git-scm.com/about/trademark) to give them a heads-up.
I like the idea of closing the gap where GitHub might fail, and I love ActivityPub-based services and the federated web, but I think this isn't the best solution. Git is already decentralized to the extent necessary to be useful for projects. An open source project will generally have one and only one canonical upstream location. If that location needs to move, git is accomodating.
The better strategy is to work on encoding ticket tracking and such into git objects, in my opinion.
Seems like a lot of work to paper over with a dubious web front end what essentially amounts to emailing a patch. I'm old... I'll go back to my pasture.
Out of curiosity, since I always wonder about ActivityPub integration between unlike apps: If a Git server used GitPub, could I comment on a PR from my Mastodon account?
It all depends on the vocabulary used. The Mastodon vocabulary is well defined already, but no vocabulary has been defined for GitPub for the time being.
Hopefully, GitPub will be the thinnest possible addition to ActivityPub, so that concepts (and vocabulary) are shared between GitPub and Mastodon, enabling comments between them.
I would be surprised if Github implements this. Especially with the Microsoft purchase. Microsoft is known for building walled gardens, not knocking them down. Why would they expend effort to make life easier for competitors?
> Aardwolf, Bridgy Fed, distbin.com, dokieli, Funkwhale, Hubzilla, Kroeg, Mastodon, Nextcloud, Numaverse, PeerTube, places.pub, Pubstrate, Smilodon, tags.pub, Pleroma, Pump.io, and Rustodon are all either implementors of or are currently implementing ActivityPub.
In addition to those, https://pixelfed.org/ is in the process of implementing federation with AP.
