4 ms·

A few things: I think you're using too much hyperbole -- it's all relative, and if you think Gitlab's UI is the bottom of the pile, you haven't used enough sof

A few things: I think you're using too much hyperbole -- it's all relative, and if you think Gitlab's UI is the bottom of the pile, you haven't used enough software and truly seen what bad UI looks like. I'm not saying UI doesn't matter, I'm just saying what they have is workable (and can get better, and they've expressed that they care to improve it). Email, IDE, Editors are not the same as your code hosting, testing, deployment tool, that's a false equivalency. Maybe I must be the only one that is OK waiting 20 seconds for a merge request to complete. I don't think it is reasonable to hold the fact that they copied/mimiced Github's functionality or UI when they started out against them. Society couldn't move forward if people didn't recycle and improve ideas. As far as the differences go, while what you said might have been true, it's not these days. Also, you haven't addressed the point that Gitlab offers a shorter path to Doing It Right (tm) (albeit a pretty subjective definition of "right") than Github does.

u801e 9y ago
> Email, IDE, Editors are not the same as your code hosting, testing, deployment tool Why should hosting, testing, and deployment be handled by the same tool (as opposed to tools that handle each need individually)?
- hardwaresofton 9y ago
  That's a good question -- and of course, the answer is it depends. Having small focused tools is great, but that's only when the substrate/platform that lets you combine them is suuuuper good/standardized/well-designed. `cat file.txt | sort | uniq` is excellent, but I think a lot of the ergonomics of that kind of small/focused tool reusability is due to the super low friction of using pipe, and how well STDIN, STDOUT, and STDERR work behind the scenes. This kind of falls apart when you try and string together web services. In my opinion, Gitlab's inclusion of so many parts of the process is good because it saves you from having to manage all the other tools, and it gives you answers for the complete process (where it's possible you could get painted into a corner depending on which focused tools you picked to do some pieces of the process, and have to write your own glue or go on a long search).

u801e 9y ago

> Email, IDE, Editors are not the same as your code hosting, testing, deployment tool Why should hosting, testing, and deployment be handled by the same tool (as opposed to tools that handle each need individually)?

hardwaresofton 9y ago
That's a good question -- and of course, the answer is it depends. Having small focused tools is great, but that's only when the substrate/platform that lets you combine them is suuuuper good/standardized/well-designed. `cat file.txt | sort | uniq` is excellent, but I think a lot of the ergonomics of that kind of small/focused tool reusability is due to the super low friction of using pipe, and how well STDIN, STDOUT, and STDERR work behind the scenes. This kind of falls apart when you try and string together web services. In my opinion, Gitlab's inclusion of so many parts of the process is good because it saves you from having to manage all the other tools, and it gives you answers for the complete process (where it's possible you could get painted into a corner depending on which focused tools you picked to do some pieces of the process, and have to write your own glue or go on a long search).