4 ms·

I think the explanation does not make any sense in 2023, if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or

by Thaxll 3y ago

I think the explanation does not make any sense in 2023, if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. If you want to make your project more open to contribution you have to use what the rest of the industry is using. Edit: After reading some responses, I'm really surprised that sqlite does not accept contributions.

enigmurl 3y ago
Sure, but with that kind of argument will we ever be able to make the switch to a better vcs if one exists? You have to start somewhere.
casion 3y ago
> If you want to make your project more open to contribution This is a key point, and assuming this in the positive is often a mistake. Not all projects want, or can handle, increased contribution.
- grayhatter 3y ago
  sqlite is actually a perfect example of a project that specifically excludes public code contribution. https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html
upon_drumhead 3y ago
> If you want to make your project more open to contribution you have to use what the rest of the industry is using. They don't want contributions https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html > In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches.
- eska 3y ago
  > from people who have not submitted an affidavit dedicating their contribution into the public domain. Don’t spread FUD
  - upon_drumhead 3y ago
    Here you go. https://sqlite.org/forum/forumpost/860f855ed144703d https://sqlite.org/forum/forumpost/860f855ed144703d > The project requires a document on file but it doesn't accept that document from arbitrary people. It's effectively "by invitation only" and Richard hands out those invitations at his sole discretion.
    - eska 3y ago
      In that case I apologize. What a disingenuous statement on the website, then.
      - nmz 3y ago
        I wouldn't classify it as disingenous, legalities are difficult, especially when you can't afford github's infrastructure and lawyers to write you up a CLA and a userbase that is not even aware of the TOS they're agreeing to. It's the only way to go.
eska 3y ago
Says who?
samspenc 3y ago
I upvoted the post since I think it's a overall interesting technical discussion of git's downsides and some fossil upsides. But my response would be the same as what I argue in these React or other "popular-vs-other-frameworks" discussions that come: the alternatives may be better, faster, easier etc - BUT: - The popular solution has the larger ecosystem, and there are more existing plugins or modules you can plug-and-play instead of having to build out your own solution for. - If you hit any edge case or obscure issues with the popular framework, someone somewhere on the Internet has hit it and it's likely a QA on Stackoverflow / Reddit and similar (and hence ChatGPT and other LLMs as a result) - People understand the popular solution more in depth and it's easier to learn about the architecture as well as its pros and cons.
- hotshiitake 3y ago
  Counterpoint - I get the same spiel from SEO marketing people trying to justify why every website in the org (including LoB web apps, intranet sites, etc.) needs to be a WordPress instance with 50 or so insecure plugins each. "But it's so popular!".
- duxup 3y ago
  >I upvoted the post since I think it's a overall interesting technical discussion of git's downsides and some fossil upsides. Agreed, I disagree with the other person's point of view, but I find it an interesting point / discussion.
pengaru 3y ago
The average contribution via something like github is just a waste of time, especially if a project is popular having many users.
reaperducer 3y ago
if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. That's pretty much the opposite of progress. At one time, 99.9% of developers used CP/M. At time, 99.9% of web was done in PHP. At one time, 99.9% of developers IBM XTs. At one time 99.9% of developers used SourceForce and SVN. Stuff changes. Monoculture is bad for the tech industry.
- deleted 3y ago
  [deleted]
- inferiorhuman 3y ago
  On the one hand I'm inclined to agree about monoculture, on the other I've worked at a company where one employee dictated that we use bzr. Basically everything was an order of magnitude more difficult through minimal fault of bzr. None of the third party tooling worked with bzr, or if something did have bzr support it was dropped ages ago. It's kind of the same situation with Github. The pain in moving away from it as they continue to slaughter the UX is still pretty great. So yeah monoculture is bad but progress is painful.
  - Brian_K_White 3y ago
    To me that just sounds like an example of the reason to avoid tight coupling. If something breaks beacause it cares that I use git and only git, then it's that something that is broken and to be avoided, not the git alternative.
  - paulryanrogers 3y ago
    Having been that person (albeit before Git was the one true way), I'm sorry. But seemed so nice and had solid externals and sparse checkouts back in the day. And as bad as it got for us, it still felt easier to pick up and use than early Git.
    - inferiorhuman 3y ago
      Sure, and I was that person with the svn -> git migration at a different gig. Ideally our behavior matures over time. For me, at least, two things eventually made git really manageable: github and the O'Reilly book. After those git was a no brainer. Even with git becoming the de facto standard, if you don't need the integrations it's not so unreasonable to use something else (altho bzr's been discontinued).
em-bee 3y ago
well, it is not that difficult to convert from one revision control system to another, at least among git, mercurial, bazaar and other equally featureful systems, which includes fossil too i would expect. maybe some of them are more featureful and track stuff that git doesn't so conversion would loose some data, but i don't see that as a problem. (a lesser system that doesn't track everything git has might be an issue, but actually not even that, since all we need is interoperability not full conversion) mercurial has a plugin to support git, and the reverse exists too. for bazaar as well. interestingly fossil can export to git, and a git repo can be converted, but it can't pull updates from git into fossil. i wonder why. anyways, the point is, because interoperability exists and is possible there is no technical reason not to use alternative tools despite everyone else using git.
bsder 3y ago
> I think the explanation does not make any sense in 2023, if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. And this is why Microsoft is now in a monopoly position ... again ... simply by buying Github. Programmers never learn.

by Thaxll 3y ago

enigmurl 3y ago

Sure, but with that kind of argument will we ever be able to make the switch to a better vcs if one exists? You have to start somewhere.

casion 3y ago

> If you want to make your project more open to contribution This is a key point, and assuming this in the positive is often a mistake. Not all projects want, or can handle, increased contribution.

grayhatter 3y ago
sqlite is actually a perfect example of a project that specifically excludes public code contribution. https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html

upon_drumhead 3y ago

> If you want to make your project more open to contribution you have to use what the rest of the industry is using. They don't want contributions https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html > In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches.

eska 3y ago
> from people who have not submitted an affidavit dedicating their contribution into the public domain. Don’t spread FUD
- upon_drumhead 3y ago
  Here you go. https://sqlite.org/forum/forumpost/860f855ed144703d https://sqlite.org/forum/forumpost/860f855ed144703d > The project requires a document on file but it doesn't accept that document from arbitrary people. It's effectively "by invitation only" and Richard hands out those invitations at his sole discretion.
  - eska 3y ago
    In that case I apologize. What a disingenuous statement on the website, then.
    - nmz 3y ago
      I wouldn't classify it as disingenous, legalities are difficult, especially when you can't afford github's infrastructure and lawyers to write you up a CLA and a userbase that is not even aware of the TOS they're agreeing to. It's the only way to go.

eska 3y ago

Says who?

samspenc 3y ago

I upvoted the post since I think it's a overall interesting technical discussion of git's downsides and some fossil upsides. But my response would be the same as what I argue in these React or other "popular-vs-other-frameworks" discussions that come: the alternatives may be better, faster, easier etc - BUT: - The popular solution has the larger ecosystem, and there are more existing plugins or modules you can plug-and-play instead of having to build out your own solution for. - If you hit any edge case or obscure issues with the popular framework, someone somewhere on the Internet has hit it and it's likely a QA on Stackoverflow / Reddit and similar (and hence ChatGPT and other LLMs as a result) - People understand the popular solution more in depth and it's easier to learn about the architecture as well as its pros and cons.

hotshiitake 3y ago
Counterpoint - I get the same spiel from SEO marketing people trying to justify why every website in the org (including LoB web apps, intranet sites, etc.) needs to be a WordPress instance with 50 or so insecure plugins each. "But it's so popular!".
duxup 3y ago
>I upvoted the post since I think it's a overall interesting technical discussion of git's downsides and some fossil upsides. Agreed, I disagree with the other person's point of view, but I find it an interesting point / discussion.

pengaru 3y ago

The average contribution via something like github is just a waste of time, especially if a project is popular having many users.

reaperducer 3y ago

if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. That's pretty much the opposite of progress. At one time, 99.9% of developers used CP/M. At time, 99.9% of web was done in PHP. At one time, 99.9% of developers IBM XTs. At one time 99.9% of developers used SourceForce and SVN. Stuff changes. Monoculture is bad for the tech industry.

deleted 3y ago
[deleted]
inferiorhuman 3y ago
On the one hand I'm inclined to agree about monoculture, on the other I've worked at a company where one employee dictated that we use bzr. Basically everything was an order of magnitude more difficult through minimal fault of bzr. None of the third party tooling worked with bzr, or if something did have bzr support it was dropped ages ago. It's kind of the same situation with Github. The pain in moving away from it as they continue to slaughter the UX is still pretty great. So yeah monoculture is bad but progress is painful.
- Brian_K_White 3y ago
  To me that just sounds like an example of the reason to avoid tight coupling. If something breaks beacause it cares that I use git and only git, then it's that something that is broken and to be avoided, not the git alternative.
- paulryanrogers 3y ago
  Having been that person (albeit before Git was the one true way), I'm sorry. But seemed so nice and had solid externals and sparse checkouts back in the day. And as bad as it got for us, it still felt easier to pick up and use than early Git.
  - inferiorhuman 3y ago
    Sure, and I was that person with the svn -> git migration at a different gig. Ideally our behavior matures over time. For me, at least, two things eventually made git really manageable: github and the O'Reilly book. After those git was a no brainer. Even with git becoming the de facto standard, if you don't need the integrations it's not so unreasonable to use something else (altho bzr's been discontinued).

em-bee 3y ago

well, it is not that difficult to convert from one revision control system to another, at least among git, mercurial, bazaar and other equally featureful systems, which includes fossil too i would expect. maybe some of them are more featureful and track stuff that git doesn't so conversion would loose some data, but i don't see that as a problem. (a lesser system that doesn't track everything git has might be an issue, but actually not even that, since all we need is interoperability not full conversion) mercurial has a plugin to support git, and the reverse exists too. for bazaar as well. interestingly fossil can export to git, and a git repo can be converted, but it can't pull updates from git into fossil. i wonder why. anyways, the point is, because interoperability exists and is possible there is no technical reason not to use alternative tools despite everyone else using git.

bsder 3y ago

> I think the explanation does not make any sense in 2023, if 99.99% of dev use Git you have to use Git, using your own solution that no one else uses or know or need to know is bad. And this is why Microsoft is now in a monopoly position ... again ... simply by buying Github. Programmers never learn.