On Thursday, 7 June 2018 at 19:02:31 UTC, Russel Winder wrote:
On Thu, 2018-06-07 at 10:17 -0700, H. S. Teoh via
Digitalmars-d-announce wrote:
[…]
Exactly!!! Git was built precisely for decentralized,
distributed development. Anyone should be (and is, if they
bothered to put just a tiny amount of effort into it) able to
set up a git server and send the URL to prospective
collaborators. Anyone is free to clone the git repo and
redistribute that clone to anyone else. Anyone can create new
commits in a local clone and send the URL to another
collaborator who can pull the commits. It should never have
become the tool to build walled gardens that inhibit this free
sharing of code.
I think there is an interesting tension between using a DVCS as
a DVCS and no central resource, and thus no mainline version,
and using a DVCS in combination with a central resource. In
the latter category the central resource may just be the
repository acting as the mainline, or, as with GitHub, GitLab,
Launchpad, the central resource provides sharing and reviewing
support.
Very few organisations, except perhaps those that use Fossil,
actually use DVCS as a DVCS. Everyone seems to want a public
mainline version: the repository that represents the official
state of the project. It seems the world is not capable of
working with a DVCS system that does not even support
"eventually consistent". Perhaps because of lack of trying or
perhaps because the idea of the mainline version of a project
is important to projects.
Well, as Jonathan says, you have to release a build eventually,
and you need a mainline version that you know has all the needed
commits to release from.
If you have multiple people all releasing their own builds with
each build getting a roughly equivalent number of downloads, then
a mainline version may not be needed, but I know of no large
project like that.
In the past Gnome, Debian, GStreamer, and many others have had
a central mainline Git repository and everything was handled as
DVCS, with emailed patches. They tended not to support using
remotes and merges via that route, not entirely sure why.
GitHub and GitLab supported forking, issues, pull requests, and
CI. So many people have found this useful. Not just for having
ready made CI on PRs, but because there was a central place
that lots of projects were at, there was lots of serendipitous
contribution. Gnome, Debian, and GStreamer are moving to
private GitLab instances. It seems the use of a bare Git
repository is not as appealing to these projects as having the
support of a centralised system.
Nobody uses a DVCS alone, even the linux kernel guys have mailing
lists and other software they use to coordinate with around git.
I think that whilst there are many technical reasons for having
an element of process support at the mainline location
favouring the GitHubs and GitLabs of this Gitty world, a lot of
it is about the people and the social system: there is a sense
of belonging, a sense of accessibility, and being able to
contribute more easily.
There is some of that, but you could reproduce all of that in a
technically decentralized manner.
One of the aspects of the total DVCS is that it can exclude, it
is in itself a walled garden, you have to be in the clique to
even know the activity is happening.
Right now, yes, mailing lists and bugzilla can be forbidding to
the noob, compared to just signing up on github and getting
everything at one go. But as Basile's link above points out,
there are tools like git-ssb that try decentralize all that:
http://git-ssb.celehner.com/%25RPKzL382v2fAia5HuDNHD5kkFdlP7bGvXQApSXqOBwc%3D.sha256
All of this is not just technical, it is socio-technical.
It is all ultimately technical, but yes, social elements come
into play.
One big thing that web software like github or trac helps with is
reviewing pulls to the main repo. I'm not about to add dozens of
remotes to my local repo to review pulls from all the
contributors to dmd/druntime/phobos, the github pull review
workflow is much easier than the git command-line equivalent.
However, it wouldn't be that hard to decentralize most of what
github provides by coming up with a standard format to store
issues and other discussion in a git repo, as I'm guessing
git-ssb does. The only aspect that might present difficulty is
that you may not get as nice a web viewer as github provided, as
the built-in gitweb is not very good compared to github's web UI.
In that way, while many are complaining about using github, the
OSS community doing so for all these years may have been optimal,
in that as long as a money-losing company was willing to do that
work for you for years, why not use it? Where was all that money
being lost after all, if not on providing features to users who
weren't paying enough to sustain it? Then, once you know whether
github's business model works or not, apparently not, you
consider moving elsewhere.
I don't know why some people are making a big deal about losing
data with github, I can't imagine it'd be that hard to scrape.
Gitlab has an exporter, you could simply repurpose that for your
own uses. You may not get everything, like user permissions or
some other internal controls, but you'd get everything that
really matters.
