So far, I am happy only using pure git.
If you guys that use GitLab or GitHub or alike would have to switch to pure git - what is the one thing you would miss most?
If you guys that use GitLab or GitHub or alike would have to switch to pure git - what is the one thing you would miss most?
- Issue tracker
- Merge requests that are easy to analyze
- Ability to put comments during a code review on specific lines of code and discuss it from there
- Embedded wiki for a project
- Managing different access rights to different repos
I couldn't see myself using pure git without any additional tooling for anything more that personal projects that I work on alone.
Because Atlassian manages to extract boatloads of enterprise money for a product portfolio that can be best described as an inconsistent, unintegrated mess.
Everything they have was bought together and crudely integrated, with each product having totally different ways of using and administrating them. Not to mention that core features (e.g. "merging" duplicate user accounts, SAML login) are paid-for plugins of varying quality. Feature suggestions for the products end up in multi-year-old tickets that one has no way to influence.
But still, enterprises are buying up that crap because the alternatives to JIRA and Confluence plainly suck even more. The only thing that has real competition is Bitbucket, with Gitlab and Github as more than viable alternatives.
One such 'feature request' is 'unsubscribe from email': https://community.atlassian.com/t5/Jira-questions/How-can-us...
Mental.
I have a rule to send it all to spam.
That's like asking if shitty burgers really "justify mcdonalds valuation".
Maybe you are not impressed with the product, but millions of people are interested in buying it.
For years Gitlab had a better offer then Github, and yet github was always more popular due to the network effect.
It’s pretty hard to claim a technical moat when most of what you sell can be replicated with a repo fork.
Without signing a contract or even having the board or upper management discuss it, the organization is now entrenched with this piece of software. Comes along a new regulation for your industry; GPDR, SOX, HIPAA, etc. It doesn't matter. What do you do? Fortunately, the provider of your "open source" (or rather: open core) solution offers features supporting your use case. You just have to upgrade from the MIT-licensed core, community edition to the enterprise edition, for $xx,xxx per year.
When arguing why it’s better than alternatives, the talking point is that “it’s open-source!” But when it’s (rightfully) pointed out that this doesn’t leave much of a defensive moat, the open-source philosophy gets thrown under the bus.
Yes, yes...it’s “open core”. That just means that it’s 10% more difficult to clone and replicate the business. Mark my words: someday, Gitlab will do something to piss off the “community”, and this will quickly happen.
It doesn't matter if you can clone it exactly tomorrow. Go ahead and do so. It won't give you the same valuation and it won't hurt theirs because that's not how it works.
Gitlab as a company is about a precarious as Docker as a company. Most of its users are using it for free, and the few that are paying would happily pay anyone else who provided support for the same software. It’s a commodity.
But yes, many people also pay Gitlab for enterprise features (which are not open-source), hosting, support, and more. If they would pay anyone else then why aren't they using Github? If they just wanted git itself then why aren't they using the numerous lightweight alternatives?
Business isn't as simple as replicating a product, it's about selling value, and Gitlab has a unique solution that covers the entire software lifecycle. I'm sure you know all this but yet you've made numerous posts disparaging this company. Why, exactly?
True, you could start a burger chain for a lot less than $10m...
source: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<BVRVZEWYB30Q.3H...
You are greatly overestimating your abilities.
Markdown is already rendered in the repo and can live next to the code. Meaning that merge requests can update both the code and documentation at the same time. And GitLab / GitHub have embedded editors that allow you to edit the markdown files using from the browser, just like a wiki.
Basically the only thing that is left is that the wiki can be edited without supervision.
Then again I'm not sure how many non-technical folks are willing to dig into GH anyway. I've heard Issues & friends called "too confusing" for "non-technical" folks, in favor of Asana and Jira, of all things. Huge WTF from me since I'd say the opposite is strongly true regardless how "technical" one is, but that's the perception I guess.
I've always been an advocate for the "markdown in the repo" scheme with CI-generated Sphinx (or whatever) docs, but these features have really won me over to the standalone wiki at least in some cases.
Yes, that's a significant difference. Publically contributed information (Wikipedia, Stack Overflow) can be quite good.
---
Another difference is that the wiki is not versioned with your code. (An entirely separate repo, but stil logically connected with the code repo.)
HEAD of wiki is documentation for version 1, version 2, version 3, etc. of your code.
That may be a good thing; that may be a bad thing.
There are bug trackers that have more features compared to Github/Gitlab.
> Merge requests that are easy to analyze
You can get that through pure git by using git format-patch and git send-email
> Ability to put comments during a code review on specific lines of code and discuss it from there
You can get that by replying inline to the email containing the patch (much like I'm doing here when replying to a certain part of your comment).
> Embedded wiki for a project
That could be maintained in the docs directory of the project
> Managing different access rights to different repos
Given that the project maintainer(s) maintain access to their repos, they could just as well handle the access rights without having to rely on Github/Gitlab.
- Search (across code, issues, pull requests etc)
- Issue tracker (~ manage my backlog, write down potential ideas)
- Pull requests, review UI around them
- GitHub Apps and Actions (~ automation) and integration with third-party tools (auto-deploy changes to zeit.co / netlify / heroku etc).
- Security audits (GitHub can send pull requests to bump my dependencies when security vulns are discovered in them)
- Ability to contribute without having to fork/clone/push changes (I quite often contribute to projects by editing the code directly through the GitHub website).
Whenever I do that I get as far as the commit message and, lacking vi and a 72 char marker, commit 'wip', pull down the changes, amend the commit, and wish I'd done the whole thing locally faster and more easily in the first place.
Is it you or the project owners who care about the 72 character limit? IME most projects will accept contributions regardless of formatting of the commit message. Most people are just happy about contributions, regardless of source.
When you work in a team and want to be productive, pure Git just doesn't provides the tools.
Also comments on issues are a crucial part of the documentation for devs.
"Looks like this does not work as documented" "Yes, this corner case is a bug, will be fixed soon, use this workaround in the meantime".
These projects too will benefit from a independent CI-service validating their commits.
Generally speaking you'd set up your own "synchronisation channel(s)" for such tools e.g. mailing lists.
The point of github / gitlab / etc is to have all the tools in one place, nicely integrated
I personally feel gitlab/github are useful from community and collaboration aspects - there is nothing I couldn't do without github on my solo projects from purely technical point of view, it's strengths are issue tracking, pull requests, wikis, distribution of code.
Primarily they're communities which grow in value based on the number of developers and projects hosted within them.
Some of the powerful resulting centralized features are:
* The social / team functionality - collaborating on code review, receiving notifications on repository activity, managing access control across multiple codebases
* Code discovery - the ability to find projects which use a particular library, search for (and subscribe to) issue reports/fixes, follow other developers' activity
These could more-or-less be achieved by configuring individual repos and setting up your own email alerts and notifications; GitHub & GitLab just make it very convenient and bring it all together in a single place.
You can use something like GitHub/GitLab for most all of these tasks, but it's a bit overkill on things like maintenance and hardware requirements if your needs aren't great.
In terms of what I would miss if we had to move away from GitLab, it's having remote repository management and continuous integration in one spot. In the past when a new project started, an administrator had to setup the repository and link in SSH keys, that same person had to setup Jenkins for the CI workflow. With GitLab, developers can set these things up on their own.
And there's one less tool to manage.
Github & Gitlab do tons of things which pure Git does not:
- issue-tracking
- wikis / documentation
- release and package-management
- CI
- a free of cost (and effort) "public facing website" for your project by default
- notifications to collaborators
https://her.esy.fun/slides/git-project-manager.html
Mostly, project-management features.
On my local machine, there's nothing stopping me from using any Git client I want, including the Git CLI..
To a one-click view of CI pipelines, that's nice too.
You could replace those with TODO/FIXME comments in the code and .md files checked in git though.
Fossil seems to offer the best of both worlds, but unfortunately it's too confidential and no one else seems to use it.