10 ms·

What advantages do people like from Gitlab as opposed to just using git? I'm not too familiar with gitlab/github, so I'm sure it's a naive question, but I'm wo

by nfoz 6y ago

What advantages do people like from Gitlab as opposed to just using git? I'm not too familiar with gitlab/github, so I'm sure it's a naive question, but I'm wondering what the main value-add that's missing from the basic tools is?

Denvercoder9 6y ago
CI, issue tracker, pull requests, etc.
beisner 6y ago
Git is a version control system, whereas Gitlab/Github are source-code hosting applications. You use git to interact with Gitlab/Github. Without going too in-depth, they allow teams to set up accounts on a central website, where team members can contribute to that central git repository. There are also other project-management features baked into the tool (code review, issue tracking, etc). Of course, this can all be done using a bare git server running on some publicly-available computer, but they offer nice UIs and very friendly onboarding so that makes them attractive for teams.
- ebg13 6y ago
  > whereas Gitlab/Github are source-code hosting applications I would amend that to "source-code collaboration applications". The hosting is not the important part.
thaumaturgy 6y ago
Fair question, you shouldn't be getting downvoted for it imo. Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request. When these are set up and run well, they are very powerful for mid-to-larger organizations.
- fimbulvetr 6y ago
  I would like to second this and point out that while someone can self host and set all of this stuff up, at some points there are economies of scale for using a provider to do this because the provider's raison d'etre is to create these interfaces that make it easy for everyone to interact with git. The developers on KDE, etc. probably don't want to spend their time working on the UI for their bug/issue/feature/commit request tool when they could be working on KDE things. Finally, there's the fact that many more users will be familiar with GitLab (or GitHub, BitBucket, and so on) than they would with each and every opensource project's flavor of bug/issue/feature/commit tracker. For instance, I know exactly how to find the "releases" section on github quickly - if KDE wrote their own bug/issue/feature/commit tracker, I'd have to find the "releases" area and remember where it is every time since I don't use that UI as often as I use github.
  - eyegor 6y ago
    Actually, gitlab is open source and the majority of the features aren't pay walled off. You can self host ~70% of the gitlab features on your own hardware, without paying a dime. Or you can self host and pay a subscription to enable all the enterprise features. At work, we use this for code which is too sensitive to host outside of our infrastructure. Closed source development needs management too.
- deadbunny 6y ago
  I would say that hosting on a centralised service like GitHub it Gitlab also reduces friction for contributors - bug reports, code, docs - as people will usually already have an account so they can make drive by contributions. Having to find a bug tracker, create an account, log a bug is a lot of hassle for a random library or small project. I know I've given up raising bugs for some things as I couldn't be bothered with the rigmarole of sign-up, verification, etc... On Gitlab/GitHub there is much less friction because I use both regularly and and can use them for multiple projects, large and small.
- Carpetsmoker 6y ago
  > Fair question, you shouldn't be getting downvoted for it imo. Well, the question is pretty much answered in the actual article. From the looks of it, this seems to be responding to just the title without having actually read the page.
melling 6y ago
I’d like to know also. Gitlab appears to have a free account too; I do pay for Github. Do people use both? Someone mentioned online that Gitlab has a richer markdown format. I haven’t really investigated but I found this a moment ago: https://docs.gitlab.com/ee/user/markdown.html https://docs.gitlab.com/ee/user/markdown.html
- KayL 6y ago
  linkbreak in GitLab is a headcahe for our users https://docs.gitlab.com/ee/user/markdown.html#line-breaks https://docs.gitlab.com/ee/user/markdown.html#line-breaks free GitLab account has no edit history. I think it's a important feature for private development
  - gabeweaver 6y ago
    What specifically about line breaks is a headache? Would you prefer that pressing "Enter" automatically inserted a line break? As for edit history, I'm assuming you are talking about the description edit history. If so, we had an open conversation (https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_206481815 https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_206...) about why we placed the feature in Starter and above. If you'd like to continue the convo, please open a new issue with your proposal. If you are talking about a different edit history, please clarify so I can better understand your perspective. Thank you for the feedback!
    - KayL 6y ago
      Yes, I perferred "Enter" for linebreak. Double "Enter" just not the best for us. Sometimes, we drafted the comment or description somehwere before copy into Gitlab. All lose! Some of our customers given up to fix the format and post screenshot PHOTO directly. It's very frustrating. Regarding the edit history, both description & comments edit history are important to me. We can only afford our freequent customers and one time projects. You know, many projects holding for months and no earning at all but you can't cut it.
      - 6y ago
jfkebwjsbx 6y ago
When those projects started, not much. They offered Git storage and an issue list, pretty much. Then they started to grow, specially GitLab in the beginning, and now try to be a single centralized solution for all software development needs like Atlassian, IBM and others had always been selling.
lotyrin 6y ago
Gitlab has an opinionated (and mostly open source) toolchain and set of practices for proposing, implementing, validating, operating, and monitoring software and changes to that software built on top of Git at one end and Kubernetes at the other, with lots of configurable escape hatches to override its smart defaults when/if you need to. I haven't really seen anything else quite like it (though it does have a long way to go still). People try to roll their own from-scratch solutions or plug in an off the shelf tool here or there and their idea-to-production pipelines are generally worse or incomplete in comparison. Most of the architects of these things only care about their corner of the solution space and the rest are either neglected or have their own champions and their own siloed solutions. Nothing off the shelf quite resembles it either. If you e.g. buy and use the entire Atlassian suite and train and get everyone to agree on the desired flows and practices, so much is left to you to design that no two such systems are likely to be similar, nor (in my experience) is any one such system likely to be very effective or efficient in daily use. I'd really enjoy seeing Gitlab mature and expand, I would love to work at an org that adjusted itself to fit something like what Gitlab is trying to be, instead of trying to make their hodgepodge of tools adhere to their personal tastes and political dynamics, etc. (a Sisyphean task as those landscapes are under constant arbitrary change).
- Lutger 6y ago
  This is it. Most other answers focus on one or two things gitlab does, but the essence of Gitlab is that they provide a platform for the whole development cycle, including planning, design, deployment, monitoring, analytics, incident management, etc. They can do this by using the best / most fitting open source software for each task and integrating it, also by focusing mostly on kubernetes while still providing enough flexibility for other options. You just don't get to use the whole feature set if you're not on kubernetes.
Scarblac 6y ago
Pull requests are the thing they offer that is closest to Git itself but not available in the base Git. It's a code reviewing tool to use before merging branches. Developer A has a branch that he wants to merge with the master branch. He opens a pull request for that merge, and Developer B can look at the diff online and _comment on it_. On individual lines or blocks, or on the PR as a whole. The comments can become discussions, new commits can be added to the pull request and the comments are marked as outdated if that code was updated, when everything is OK developer B can press an "Approve" button and the branch can be merged.
- Stratoscope 6y ago
  A note on terminology: GitHub and GitLab have similar features. GitHub calls them pull requests. GitLab calls them merge requests.
  - raister 6y ago
    Pull/Push is a nightmare for Portuguese (Portugal,Brazil) because 'puxar' (read push-ah-r) means pull................
    - Stratoscope 6y ago
      Ah yes! It happens in English too: "Press Enter to exit, Exit to cancel, or Cancel to continue."
- u801e 6y ago
  > Pull requests are the thing they offer that is closest to Git itself but not available in the base Git They are available in base git. The command is called request-pull[1]. [1] https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull
  - tdeck 6y ago
    As far as I can tell, all this does is generate some text that you can email to someone. It doesn't offer the ability to iterate on code reviews or track line comments, so you'd have to manage all that either via email or via a separate system.
de6u99er 6y ago
GitHub and GitLab add project management capabilities to your project. Both come with a IssueTracker (for bugs, feature requests, ...), a Wiki (for documentation), simple user management, and webhooks for automated build platforms. You can do things like adding an issue-id into a commit statement which displays your commit in the issue ticket for others to reproduce what exactly was changed to fix a bug or implement a new feature. This can be super helpful when someone wants to extend a feature. Or reproduce why something isn't working any more, and fixing it instead of reverting the code and reintroducing a bug that was fixed (We had exactly such a problem of a reoccurring bug because two dev's didn't understand each others commits) I prefer using GitLab for my company and private projects, since Microsoft has acquired GitHub. For public projects I prefer GitHub because the user community is larger. GitLab also comes with extensive project management and DevOps support, and can run on your own infrastructure.
- g105b 6y ago
  You can run Github on your own infrastructure too, so is the only benefit of GitLab that it isn't owned by Microsoft (the largest contributor to The Linux Foundation since 2005)?
  - burkaman 6y ago
    Github Enterprise is $21 per user per month, and GitLab Community Edition is free.
    - techntoke 6y ago
      It is free and open source, unlike GitHub
      - randylahey 6y ago
        I prefer Gitlab for private installs, but the community edition lacks many critical features that are only present in the paid version (export/import of issues, I'm looking at you)
shmerl 6y ago
Gitlab is replacing Phabricator, not Git. It's a higher level tool.
- brnt 6y ago
  Aha. I was already thinking: what does Gitlab add next to Phabricator? And the KDE Bugzilla instance. Will that be moved over as well? KDE has many parallel systems like that unfortunately.
  - otterlicious 6y ago
    Gitlab is replacing Phabricator but not Bugzilla. Gitlab issues are going to be used for developer task tracking but Bugzilla will continue to be used for end-user bug tracking.
    - shmerl 6y ago
      Why not Bugzilla though? Gitlab bug tracking looks much better to me. The switch worked pretty well for Mesa which was also using Bugzilla before. Bugzilla feels clunky in comparison.
      - marcthe12 6y ago
        Prob since KDE has an automated crash reporter system.
        shmerl 6y ago
        Why can't it be integrated with Gitlab? And if some old one is hardcoded to use Bugzilla, there can be automatic import to Gitlab as well. I.e. Bugzilla can run for those automatic reports, but not for anything else.
      - otterlicious 6y ago
        * KDE has gone through CVS, SVN, Git, Redmine, ReviewBoard, Phabricator and now GitLab for various source control needs over the years, all while still using Bugzilla for bug tracking. There is a lot more intertia to overcome. * GitLab (and GitHub etc.) are organized around code repos but the hierarchy you use to organize your code isn't necessarily the best hierarchy to organize your bugs. There are a few different "plasma" repositories but end users aren't going to know which one the bug about their panel spazzing out on leap seconds goes in. So you consolidate everything into one Plasma project. But then your code and bugs aren't living together anymore, and using GitLab for the bugs buys you very little over just having good integration with Bugzilla. * It's a lot easier to move bugs around between projects and they keep the same identifying number.
bra-ket 6y ago
no master->main renaming bullshit
mekoka 6y ago
Git is still what you use to manage your project's "snapshots" at any given time. But GitHub/GitLab add a plethora of tools to make it easier to manage your project and facilitate collaboration. In addition of offering the service, GitLab gives the possibility to host your own copy of their solution (it's open source).
kissgyorgy 6y ago
No offense, but if you are at a point when you don't know what a good project management system is good for, you should absolutely read this: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
paxys 6y ago
Most of the replies to your post are inaccurate. Yes Gitlab and Github offer a ton of value-adds like issue tracking and project management, but the core reason for using them is to get a fully managed Git server vs hosting one yourself.
- dijit 6y ago
  Pish. If you have ssh access to a box; you have a git remote. It’s obscenely simple, and contra to your claim the “managed” aspect is not the selling point of this software. The selling point is the project management features and integrations. In githubs case it’s a managed service. In gitlabs case, I can be a managed service or it can be a software suite you maintain yourself. Not a universal truth.
  - johannes1234321 6y ago
    The ssh host doesn't do git hosting. You have a hard time to manage ACLs and have to restrict users accordingly. Also you need to run an http server and update the git cache if you want to support anonymous requests to the repo. There's a bit more to it ... and sure all can be done manually.
    - regularfry 6y ago
      Git hosting over SSH does work. I've seen it work well. We already had ACLs set up for other reasons, and we didn't need anonymous requests. It's the simplest thing that can possibly work; don't add extra complication if it's not needed.
  - vishbar 6y ago
    Sure, so now instead of just having a source control remote, you’re now looking after a publicly accessible box in the cloud with all the security headaches that brings. Plus you’ve got to manage credentials essentially manually, make sure people have the right access permissions to repos, look after backups, etc. I worked at a company that started out with a setup like this for the dev team. It felt like a massive burden was lifted when we moved to Github Enterprise. We weren’t using the project management features at all, just the source code hosting stuff.
deleted 6y ago
[deleted]
WhyNotHugo 6y ago
Git itself doesn't offer things like merge requests, issues, permission management, etc. Think of "Linux" and "Ubuntu". The kernel is necessary, but so is all the user-space on top of it. That's git and GitLab respectively.
indymike 6y ago
First level of value is simply a hosted, reliable git hosting for any size of team. Second, is the pull or merge request workflow which really makes coordinating development a lot easier. Third, is automation - webhooks and such make it really easy to connect different tools to your repo (i.e. analysis, linters, CI/build or even deployment scripts. Fourth, there's all the documentation and project management.
- u801e 6y ago
  > webhooks and such make it really easy to connect different tools to your repo (i.e. analysis, linters, CI/build or even deployment scripts. What advantage does that have over the standard hooks[1] that git itself comes with? [1] https://git-scm.com/docs/githooks https://git-scm.com/docs/githooks
crististm 6y ago
You _can_ use only git but you get into several problems if you are in a team larger than one. Sharing code requires the git server and open network ports on your development computer. With non-static IP you can't point to your peer's computer without needing to change the remote settings every time you sync. Basically, for convenience, you will need a git server accessible to your team to sync up code in a 1-many fashion instead of the many-many raw git. Github/gitlab provide exactly that with added features on top. They differentiate by the added features only.
- u801e 6y ago
  > Sharing code requires the git server and open network ports on your development computer. Not really. It can be done via email using standard git commands like git format-patch, git send-email, and git am.
  - crististm 6y ago
    With the usual caveats applied to embedding and extracting patches from emails. I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years.
    - u801e 6y ago
      > With the usual caveats applied to embedding and extracting patches from emails. Which are? The settings in git format-patch and git send-email will handle embedding and sending. Also, as long as your email client can save emails to disk, git am can do the rest. > I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years. I've tested it with my ISP email (Comcast) and Gmail. Other than having to enable "insecure" access for Gmail, there wer e no problems at all. Hotmail/Live on the other hand, would mangle the email message.
hknapp 6y ago
I think postgres uses plain-old git for their repos. https://git.postgresql.org/gitweb/?p=postgresql.git https://git.postgresql.org/gitweb/?p=postgresql.git
lloydatkinson 6y ago
Is this a serious question?

by nfoz 6y ago

Denvercoder9 6y ago

CI, issue tracker, pull requests, etc.

beisner 6y ago

Git is a version control system, whereas Gitlab/Github are source-code hosting applications. You use git to interact with Gitlab/Github. Without going too in-depth, they allow teams to set up accounts on a central website, where team members can contribute to that central git repository. There are also other project-management features baked into the tool (code review, issue tracking, etc). Of course, this can all be done using a bare git server running on some publicly-available computer, but they offer nice UIs and very friendly onboarding so that makes them attractive for teams.

ebg13 6y ago
> whereas Gitlab/Github are source-code hosting applications I would amend that to "source-code collaboration applications". The hosting is not the important part.

thaumaturgy 6y ago

Fair question, you shouldn't be getting downvoted for it imo. Larger projects need a way to collect bug reports, feature requests, maintain documentation, and set up milestones and release schedules, at a minimum. Ideally you want all of this integrated into your vcs, so that when a developer decides to push a commit related to a specific bug or feature request, that commit gets attached to that bug or feature request. When these are set up and run well, they are very powerful for mid-to-larger organizations.

fimbulvetr 6y ago
I would like to second this and point out that while someone can self host and set all of this stuff up, at some points there are economies of scale for using a provider to do this because the provider's raison d'etre is to create these interfaces that make it easy for everyone to interact with git. The developers on KDE, etc. probably don't want to spend their time working on the UI for their bug/issue/feature/commit request tool when they could be working on KDE things. Finally, there's the fact that many more users will be familiar with GitLab (or GitHub, BitBucket, and so on) than they would with each and every opensource project's flavor of bug/issue/feature/commit tracker. For instance, I know exactly how to find the "releases" section on github quickly - if KDE wrote their own bug/issue/feature/commit tracker, I'd have to find the "releases" area and remember where it is every time since I don't use that UI as often as I use github.
- eyegor 6y ago
  Actually, gitlab is open source and the majority of the features aren't pay walled off. You can self host ~70% of the gitlab features on your own hardware, without paying a dime. Or you can self host and pay a subscription to enable all the enterprise features. At work, we use this for code which is too sensitive to host outside of our infrastructure. Closed source development needs management too.
deadbunny 6y ago
I would say that hosting on a centralised service like GitHub it Gitlab also reduces friction for contributors - bug reports, code, docs - as people will usually already have an account so they can make drive by contributions. Having to find a bug tracker, create an account, log a bug is a lot of hassle for a random library or small project. I know I've given up raising bugs for some things as I couldn't be bothered with the rigmarole of sign-up, verification, etc... On Gitlab/GitHub there is much less friction because I use both regularly and and can use them for multiple projects, large and small.
Carpetsmoker 6y ago
> Fair question, you shouldn't be getting downvoted for it imo. Well, the question is pretty much answered in the actual article. From the looks of it, this seems to be responding to just the title without having actually read the page.

melling 6y ago

I’d like to know also. Gitlab appears to have a free account too; I do pay for Github. Do people use both? Someone mentioned online that Gitlab has a richer markdown format. I haven’t really investigated but I found this a moment ago: https://docs.gitlab.com/ee/user/markdown.html https://docs.gitlab.com/ee/user/markdown.html

KayL 6y ago
linkbreak in GitLab is a headcahe for our users https://docs.gitlab.com/ee/user/markdown.html#line-breaks https://docs.gitlab.com/ee/user/markdown.html#line-breaks free GitLab account has no edit history. I think it's a important feature for private development
- gabeweaver 6y ago
  What specifically about line breaks is a headache? Would you prefer that pressing "Enter" automatically inserted a line break? As for edit history, I'm assuming you are talking about the description edit history. If so, we had an open conversation (https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_206481815 https://gitlab.com/gitlab-org/gitlab/-/issues/10103#note_206...) about why we placed the feature in Starter and above. If you'd like to continue the convo, please open a new issue with your proposal. If you are talking about a different edit history, please clarify so I can better understand your perspective. Thank you for the feedback!
  - KayL 6y ago
    Yes, I perferred "Enter" for linebreak. Double "Enter" just not the best for us. Sometimes, we drafted the comment or description somehwere before copy into Gitlab. All lose! Some of our customers given up to fix the format and post screenshot PHOTO directly. It's very frustrating. Regarding the edit history, both description & comments edit history are important to me. We can only afford our freequent customers and one time projects. You know, many projects holding for months and no earning at all but you can't cut it.
    - 6y ago

jfkebwjsbx 6y ago

When those projects started, not much. They offered Git storage and an issue list, pretty much. Then they started to grow, specially GitLab in the beginning, and now try to be a single centralized solution for all software development needs like Atlassian, IBM and others had always been selling.

lotyrin 6y ago

Gitlab has an opinionated (and mostly open source) toolchain and set of practices for proposing, implementing, validating, operating, and monitoring software and changes to that software built on top of Git at one end and Kubernetes at the other, with lots of configurable escape hatches to override its smart defaults when/if you need to. I haven't really seen anything else quite like it (though it does have a long way to go still). People try to roll their own from-scratch solutions or plug in an off the shelf tool here or there and their idea-to-production pipelines are generally worse or incomplete in comparison. Most of the architects of these things only care about their corner of the solution space and the rest are either neglected or have their own champions and their own siloed solutions. Nothing off the shelf quite resembles it either. If you e.g. buy and use the entire Atlassian suite and train and get everyone to agree on the desired flows and practices, so much is left to you to design that no two such systems are likely to be similar, nor (in my experience) is any one such system likely to be very effective or efficient in daily use. I'd really enjoy seeing Gitlab mature and expand, I would love to work at an org that adjusted itself to fit something like what Gitlab is trying to be, instead of trying to make their hodgepodge of tools adhere to their personal tastes and political dynamics, etc. (a Sisyphean task as those landscapes are under constant arbitrary change).

Lutger 6y ago
This is it. Most other answers focus on one or two things gitlab does, but the essence of Gitlab is that they provide a platform for the whole development cycle, including planning, design, deployment, monitoring, analytics, incident management, etc. They can do this by using the best / most fitting open source software for each task and integrating it, also by focusing mostly on kubernetes while still providing enough flexibility for other options. You just don't get to use the whole feature set if you're not on kubernetes.

Scarblac 6y ago

Pull requests are the thing they offer that is closest to Git itself but not available in the base Git. It's a code reviewing tool to use before merging branches. Developer A has a branch that he wants to merge with the master branch. He opens a pull request for that merge, and Developer B can look at the diff online and _comment on it_. On individual lines or blocks, or on the PR as a whole. The comments can become discussions, new commits can be added to the pull request and the comments are marked as outdated if that code was updated, when everything is OK developer B can press an "Approve" button and the branch can be merged.

Stratoscope 6y ago
A note on terminology: GitHub and GitLab have similar features. GitHub calls them pull requests. GitLab calls them merge requests.
- raister 6y ago
  Pull/Push is a nightmare for Portuguese (Portugal,Brazil) because 'puxar' (read push-ah-r) means pull................
  - Stratoscope 6y ago
    Ah yes! It happens in English too: "Press Enter to exit, Exit to cancel, or Cancel to continue."
u801e 6y ago
> Pull requests are the thing they offer that is closest to Git itself but not available in the base Git They are available in base git. The command is called request-pull[1]. [1] https://git-scm.com/docs/git-request-pull https://git-scm.com/docs/git-request-pull
- tdeck 6y ago
  As far as I can tell, all this does is generate some text that you can email to someone. It doesn't offer the ability to iterate on code reviews or track line comments, so you'd have to manage all that either via email or via a separate system.

de6u99er 6y ago

GitHub and GitLab add project management capabilities to your project. Both come with a IssueTracker (for bugs, feature requests, ...), a Wiki (for documentation), simple user management, and webhooks for automated build platforms. You can do things like adding an issue-id into a commit statement which displays your commit in the issue ticket for others to reproduce what exactly was changed to fix a bug or implement a new feature. This can be super helpful when someone wants to extend a feature. Or reproduce why something isn't working any more, and fixing it instead of reverting the code and reintroducing a bug that was fixed (We had exactly such a problem of a reoccurring bug because two dev's didn't understand each others commits) I prefer using GitLab for my company and private projects, since Microsoft has acquired GitHub. For public projects I prefer GitHub because the user community is larger. GitLab also comes with extensive project management and DevOps support, and can run on your own infrastructure.

g105b 6y ago
You can run Github on your own infrastructure too, so is the only benefit of GitLab that it isn't owned by Microsoft (the largest contributor to The Linux Foundation since 2005)?
- burkaman 6y ago
  Github Enterprise is $21 per user per month, and GitLab Community Edition is free.
  - techntoke 6y ago
    It is free and open source, unlike GitHub
    - randylahey 6y ago
      I prefer Gitlab for private installs, but the community edition lacks many critical features that are only present in the paid version (export/import of issues, I'm looking at you)

shmerl 6y ago

Gitlab is replacing Phabricator, not Git. It's a higher level tool.

brnt 6y ago
Aha. I was already thinking: what does Gitlab add next to Phabricator? And the KDE Bugzilla instance. Will that be moved over as well? KDE has many parallel systems like that unfortunately.
- otterlicious 6y ago
  Gitlab is replacing Phabricator but not Bugzilla. Gitlab issues are going to be used for developer task tracking but Bugzilla will continue to be used for end-user bug tracking.
  - shmerl 6y ago
    Why not Bugzilla though? Gitlab bug tracking looks much better to me. The switch worked pretty well for Mesa which was also using Bugzilla before. Bugzilla feels clunky in comparison.
    - marcthe12 6y ago
      Prob since KDE has an automated crash reporter system.
      - shmerl 6y ago
        Why can't it be integrated with Gitlab? And if some old one is hardcoded to use Bugzilla, there can be automatic import to Gitlab as well. I.e. Bugzilla can run for those automatic reports, but not for anything else.
    - otterlicious 6y ago
      * KDE has gone through CVS, SVN, Git, Redmine, ReviewBoard, Phabricator and now GitLab for various source control needs over the years, all while still using Bugzilla for bug tracking. There is a lot more intertia to overcome. * GitLab (and GitHub etc.) are organized around code repos but the hierarchy you use to organize your code isn't necessarily the best hierarchy to organize your bugs. There are a few different "plasma" repositories but end users aren't going to know which one the bug about their panel spazzing out on leap seconds goes in. So you consolidate everything into one Plasma project. But then your code and bugs aren't living together anymore, and using GitLab for the bugs buys you very little over just having good integration with Bugzilla. * It's a lot easier to move bugs around between projects and they keep the same identifying number.

bra-ket 6y ago

no master->main renaming bullshit

mekoka 6y ago

Git is still what you use to manage your project's "snapshots" at any given time. But GitHub/GitLab add a plethora of tools to make it easier to manage your project and facilitate collaboration. In addition of offering the service, GitLab gives the possibility to host your own copy of their solution (it's open source).

kissgyorgy 6y ago

No offense, but if you are at a point when you don't know what a good project management system is good for, you should absolutely read this: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

paxys 6y ago

Most of the replies to your post are inaccurate. Yes Gitlab and Github offer a ton of value-adds like issue tracking and project management, but the core reason for using them is to get a fully managed Git server vs hosting one yourself.

dijit 6y ago
Pish. If you have ssh access to a box; you have a git remote. It’s obscenely simple, and contra to your claim the “managed” aspect is not the selling point of this software. The selling point is the project management features and integrations. In githubs case it’s a managed service. In gitlabs case, I can be a managed service or it can be a software suite you maintain yourself. Not a universal truth.
- johannes1234321 6y ago
  The ssh host doesn't do git hosting. You have a hard time to manage ACLs and have to restrict users accordingly. Also you need to run an http server and update the git cache if you want to support anonymous requests to the repo. There's a bit more to it ... and sure all can be done manually.
  - regularfry 6y ago
    Git hosting over SSH does work. I've seen it work well. We already had ACLs set up for other reasons, and we didn't need anonymous requests. It's the simplest thing that can possibly work; don't add extra complication if it's not needed.
- vishbar 6y ago
  Sure, so now instead of just having a source control remote, you’re now looking after a publicly accessible box in the cloud with all the security headaches that brings. Plus you’ve got to manage credentials essentially manually, make sure people have the right access permissions to repos, look after backups, etc. I worked at a company that started out with a setup like this for the dev team. It felt like a massive burden was lifted when we moved to Github Enterprise. We weren’t using the project management features at all, just the source code hosting stuff.

deleted 6y ago

[deleted]

WhyNotHugo 6y ago

Git itself doesn't offer things like merge requests, issues, permission management, etc. Think of "Linux" and "Ubuntu". The kernel is necessary, but so is all the user-space on top of it. That's git and GitLab respectively.

indymike 6y ago

First level of value is simply a hosted, reliable git hosting for any size of team. Second, is the pull or merge request workflow which really makes coordinating development a lot easier. Third, is automation - webhooks and such make it really easy to connect different tools to your repo (i.e. analysis, linters, CI/build or even deployment scripts. Fourth, there's all the documentation and project management.

u801e 6y ago
> webhooks and such make it really easy to connect different tools to your repo (i.e. analysis, linters, CI/build or even deployment scripts. What advantage does that have over the standard hooks[1] that git itself comes with? [1] https://git-scm.com/docs/githooks https://git-scm.com/docs/githooks

crististm 6y ago

You _can_ use only git but you get into several problems if you are in a team larger than one. Sharing code requires the git server and open network ports on your development computer. With non-static IP you can't point to your peer's computer without needing to change the remote settings every time you sync. Basically, for convenience, you will need a git server accessible to your team to sync up code in a 1-many fashion instead of the many-many raw git. Github/gitlab provide exactly that with added features on top. They differentiate by the added features only.

u801e 6y ago
> Sharing code requires the git server and open network ports on your development computer. Not really. It can be done via email using standard git commands like git format-patch, git send-email, and git am.
- crististm 6y ago
  With the usual caveats applied to embedding and extracting patches from emails. I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years.
  - u801e 6y ago
    > With the usual caveats applied to embedding and extracting patches from emails. Which are? The settings in git format-patch and git send-email will handle embedding and sending. Also, as long as your email client can save emails to disk, git am can do the rest. > I don't find email-git much more convenient unless I've been living under a rock and it got much easier using the free email providers for git in the last few years. I've tested it with my ISP email (Comcast) and Gmail. Other than having to enable "insecure" access for Gmail, there wer e no problems at all. Hotmail/Live on the other hand, would mangle the email message.

hknapp 6y ago

I think postgres uses plain-old git for their repos. https://git.postgresql.org/gitweb/?p=postgresql.git https://git.postgresql.org/gitweb/?p=postgresql.git

lloydatkinson 6y ago

Is this a serious question?