GitLab B.V. CEO here, our open source edition has support for [1] ECDSA keys and [2] relative urls in readme's should always work. Consider giving GitLab.com a spin.
Interestingly, I recently talked to someone in an interview setting who got asked a question about git, and as soon as the interviewee started saying, "Typically I use SourceTree," the interviewer's demeanor turned sour on asking any further version control questions.
Just because someone uses a GUI for version control doesn't mean they don't understand it... I prefer the way SourceTree makes it very easy and visual to stage portions of a file, and the always-displayed tree makes it very clear how different branching and merging operations are going to happen.
Seemed like some weird attitude against a GUI source control tool... especially one specifically well-designed for a Mercurial or Git workflow.
I'm a happy SourceTree user as well. I know how to use Git in the terminal but I find SourceTree quicker to use as it lets me quickly visualise what I need to see.
It's interesting to think about. I use SourceTree for 3 things:
- new branches (I find the syntax tedious for some reason, and I like to see where I am in the tree, so I'm already looking at SourceTree's interface when I'm branching)
- deleting remote branches (see above about syntax)
- awesome diff visualization for past commits and current work
Everything else I do on the command line, because SourceTree requires just a few too many clicks for my liking. It's a shame the terminal can't have a nice diff interface like SourceTree's, otherwise I'd probably be full terminal.
Similarly, I find the GUI quicker when I'm invoking commands I don't use often enough to memorise. I prefer cleaning up commits I'm about to make easier with SourceTree as well; I can browse through the diffs, reverse some changes, ignore some files, delete others then make my commit with minimal fuss.
I think that the only excuse for this is when the work environment uses headless servers. Can't tell you how many people are just stuck in GUI when they only knew Windows Servers and than thrown into a Linux server they were helpless.
Weird. I haven't worked in a team where people used the command line for bread-and-butter source control since 1996 or so. IME it's harder (not impossible, but harder) to screw things up with fat fingers using a GUI, and pretty much every time you use SCM you're going to want a good diff view anyway. (We tend to do basic paired code review at commit time.)
It's kind of tragic; I don't think anyone would describe the git UI in flattering terms, but now that it's become a 'pons asinorum' for geek machismo it's almost impossible to replace it.
I don't personally like using git GUIs other than the occasional gitk/git gui but I've found it really helpful to give to someone with not experience who has to use git "right now" (Like in a Game Jam) and/or is not a programmer.
It is way easier to learn git through a GUI. I didn't even know what it was or what it was used for when I started, and the GUI just laid everything out and showed you what it was doing. After that, the CLI version is just applying what you already know.
For a for-profit shop like Bitbucket, there's probably a business reason for that. I certainly don't have any metrics to back this up, but I can understand how they'd want to primarily appeal to what seems to be a wider git audience.
From what I can see, whatever new functionality is being add to the site works equally well for Mercurial and Git (sans obvious differences in Hg/Git branching models). Pull Requests, Branch Permissions, Notifications, possibly something else, -- all work with Hg too. Yet they promote Git like crazy and leave Mercurial behind.
It's worse than that - it seems almost as though there aren't many people left working on the project who understand Mercurial. Case in point: stripping Mercurial changesets from a repository has been almost completely broken for many months now with little interest or activity on the bug report.
Take a look at the conversation that transpired on the blog post comments.
Here is a copy and paste from the CEO for GitLab:
GitLab B.V. CEO here, as you might know GitLab is an open source project that is similar to GitHub and Bitbucket. Because it is open source some of our 700 contributors have contributed most of the top 5 feature requests you mentioned:
You can use GitLab for free on GitLab.com with unlimited (private) repositories and collaborators. Currently we're at 5TB of repo's but it is growing fast. Feel free to reply to this comment if you have any questions.
GitLab B.V. Account manager here. I've noticed the links are broken, so here is the same comment as above, but with working links:
Take a look at the conversation that transpired on the blog post comments.
Here is a copy and past from the CEO for GitLab:
GitLab B.V. CEO here, as you might know GitLab is an open source project that is similar to GitHub and Bitbucket. Because it is open source some of our 700 contributors have contributed most of the top 5 feature requests you mentioned:
You can use GitLab for free on GitLab.com with unlimited (private) repositories and collaborators. Currently we're at 5TB of repo's but it is growing fast. Feel free to reply to this comment if you have any questions.
What is your business plan if you are allowed unlimited private repositories? (on GitLab.com) Are you only allowed to use them for non-commercial uses?
Thanks Douwe, that is indeed how we make most money. Apart from that there is a paid plan for GitLab.com that gets you email support. Otherwise all support is via forums and twitter , see https://about.gitlab.com/gitlab-com/
I used to host my own git repos on a VPS but bitbucket (for private repos) and github (for open source repos) provide so many good auxiliary services that self hosting no longer makes sense for me. Great services.
37 comments
[ 5.2 ms ] story [ 83.0 ms ] thread[1] https://bitbucket.org/site/master/issue/4222/no-support-for-... [2] https://bitbucket.org/site/master/issue/6315/relative-urls-i...
...which is almost 6 years old, and makes it hell to view PRs that involve moved files.
Interestingly, I recently talked to someone in an interview setting who got asked a question about git, and as soon as the interviewee started saying, "Typically I use SourceTree," the interviewer's demeanor turned sour on asking any further version control questions.
Just because someone uses a GUI for version control doesn't mean they don't understand it... I prefer the way SourceTree makes it very easy and visual to stage portions of a file, and the always-displayed tree makes it very clear how different branching and merging operations are going to happen.
Seemed like some weird attitude against a GUI source control tool... especially one specifically well-designed for a Mercurial or Git workflow.
- new branches (I find the syntax tedious for some reason, and I like to see where I am in the tree, so I'm already looking at SourceTree's interface when I'm branching) - deleting remote branches (see above about syntax) - awesome diff visualization for past commits and current work
Everything else I do on the command line, because SourceTree requires just a few too many clicks for my liking. It's a shame the terminal can't have a nice diff interface like SourceTree's, otherwise I'd probably be full terminal.
Weird. I haven't worked in a team where people used the command line for bread-and-butter source control since 1996 or so. IME it's harder (not impossible, but harder) to screw things up with fat fingers using a GUI, and pretty much every time you use SCM you're going to want a good diff view anyway. (We tend to do basic paired code review at commit time.)
It's kind of tragic; I don't think anyone would describe the git UI in flattering terms, but now that it's become a 'pons asinorum' for geek machismo it's almost impossible to replace it.
And I agree, SourceTree is lovely.
Here is a copy and paste from the CEO for GitLab:
GitLab B.V. CEO here, as you might know GitLab is an open source project that is similar to GitHub and Bitbucket. Because it is open source some of our 700 contributors have contributed most of the top 5 feature requests you mentioned:
1. Contributor Statistics https://bitbucket.org/site/mas... => Available on https://gitlab.com/gitlab-org/...
2. Group repositories https://bitbucket.org/site/mas... => GitLab has groups https://gitlab.com/gitlab-org/
3. Search source code https://bitbucket.org/site/mas... => Available in the top bar of every project (uses git grep on the backend) https://gitlab.com/gitlab-org/...
4. Support for 2FA => Still not in GitLab, we would love to see it and we're accepting pull/merge requests for this http://feedback.gitlab.com/for...
5. Separate permissions for wiki/issue tracker https://bitbucket.org/site/mas... => In GitLab a guest can access the issue tracker but not the source code https://gitlab.com/gitlab-org/..., this is not the case for the wiki.
You can use GitLab for free on GitLab.com with unlimited (private) repositories and collaborators. Currently we're at 5TB of repo's but it is growing fast. Feel free to reply to this comment if you have any questions.
Take a look at the conversation that transpired on the blog post comments.
Here is a copy and past from the CEO for GitLab:
GitLab B.V. CEO here, as you might know GitLab is an open source project that is similar to GitHub and Bitbucket. Because it is open source some of our 700 contributors have contributed most of the top 5 feature requests you mentioned:
1. Contributor Statistics https://bitbucket.org/site/master/issue/4307/feature-request... => Available on https://gitlab.com/gitlab-org/gitlab-ce/graphs/master
2. Group repositories https://bitbucket.org/site/master/issue/2323/create-a-way-to... => GitLab has groups https://gitlab.com/gitlab-org/
3. Search source code https://bitbucket.org/site/master/issue/2874/ability-to-sear... => Available in the top bar of every project (uses git grep on the backend) https://gitlab.com/gitlab-org/gitlab-ce
4. Support for 2FA => Still not in GitLab, we would love to see it and we're accepting pull/merge requests for this http://feedback.gitlab.com/forums/176466-general/suggestions...
5. Separate permissions for wiki/issue tracker https://bitbucket.org/site/master/issue/2462/allow-admins-to... => In GitLab a guest can access the issue tracker but not the source code https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/perm..., this is not the case for the wiki.
You can use GitLab for free on GitLab.com with unlimited (private) repositories and collaborators. Currently we're at 5TB of repo's but it is growing fast. Feel free to reply to this comment if you have any questions.