5 ms·

Just other day, I spent 30 secs (or more) looking for the repo URL on Bitbucket. Then I thought how awesome GitHub was and it really understood users. It alway

by chintan 13y ago

Just other day, I spent 30 secs (or more) looking for the repo URL on Bitbucket. Then I thought how awesome GitHub was and it really understood users. It always had the big repo url on front and top where one can never miss it. In this new design, GitHub has pushed it on to bottom right and reduced the input size. Bad Decision IMHO.

technoweenie 13y ago
The preferred URL is the one in the browser address bar: "https://github.com/{owner}/{repo}" https://github.com/{owner}/{repo}". Works great for pushing and pulling.
- dsirijus 13y ago
  Yeh, but the convenience of it here is that you may freely browse that repo (and change URL in the address bar), and still have the access to the repo URL.
  - jeremymcanally 13y ago
    The clone URL was never accessible from deeper pages.
    - moe 13y ago
      And that has always been a pain in the ass. Github needs to start fixing things rather than constantly making them worse. Whoever is in charge of their UX-design needs to be replaced.
    - dsirijus 13y ago
      I've never said it did. I said how it ought to be.
Legion 13y ago
Agreed. I use Bitbucket every day, and while it's far short of 30 seconds, I do find it takes a second or two of extra scanning to notice where the repo URL is. And it's essentially on the top right, not aggressively out of the way. Now, Github's pushing it even further out of view than Bitbucket's location.
monkmartinez 13y ago
Honest question: Is Github supposed to be about Git and code? Statement of opinion: It seems to me that Github is the leader of online code hosting. However, this position could be disrupted because, and I could be wrong, Github focuses on items not directly related to git and/or code. I dream of a time when the average person making manuals or Stand Operating Procedures in an office environment can see the benefits of source control and has tools that make git easy. The company that truly focuses on making Git itself dead simple and powerful will win. I pay github every month, but I am starting to lose my patience. I am actively looking to support a company that focuses on abstracting the completely unforgiving nature of git. In my opinion, you shouldn't need to be a command line virtuoso nor need to grok the entirety of the git code base to use git. Eventually, everyone gets dirty with git and thats when the lack thought in usability exposes itself. Github could focus on this, but it seems like they have other priorities which is fine. I have mine too.
- gjtorikian 13y ago
  Do http://mac.github.com/ http://mac.github.com/ or http://windows.github.com/ http://windows.github.com/ not work for in "abstracting the completely unforgiving nature of git"?
  - bhauer 13y ago
    They help, but as a user of Github for Windows, I have too often been told that a "synch" (basically a combination of push and pull) failed and I need to resolve the issue using my command prompt. As an anecdotal measure, I would estimate this happens about 5 to 10% of the time while working alongside my colleagues who are not using Github for Windows, or any similar GUI tool, and using our own private Gitlab origin. Github for Windows is also disappointingly lacking in functionality that is necessary in my workgroup. For example, it does not support Git submodules or two-origin configurations. When I work in repositories we have configured in that fashion, the command line is my option of choice. And let me be frank: there are scarcely any tools I use that have a worse user interface than the Git command line tool. I agree with the grandparent that there remains a market under-served: to provide a decent user interface on top of Git. Github for Windows is amazing for a free tool and I give the development team a great deal of respect for what they have provided users like myself (people who want their source control and build tools to just do their job simply and get the heck out of the way). But there is a lot of room for improvement. I for one would pay good money for a Github for Windows "Professional" version.
MattRix 13y ago
Yeah but by the time you've used the site a couple times, you'll be able to find the repo url from then on. It really doesn't make any sense being at the top of the page taking up so much prime space.
simonz05 13y ago
They added a green button which i assume is "fork on github". It seems they want to encourage people to use github rather to clone to local filesystem.
- xixixao 13y ago
  Nope, that one is for pull requests. But they did disable SSH cloning for read-only and the cloning URL is not showing at all (only after you click on HTTPS), pointing towards preferring of forking.
- shardling 13y ago
  They've always had a quite prominent "fork on github" button. Their suggested course of action is to fork on github and then clone to your local filesystem. You then push changes to your fork on github, and open a pull request from within their system. The default workflow is designed to play nice with their issue tracker/etc.
kawsper 13y ago
I spend way too long looking for the repo URL. Too bad they have hidden it away, I think it is one of the most used features in a repo.
- nunb 13y ago
  Presumably, by the fifth time this happens, it'll be seared in your brain. And the browser url is already prominent.
  - kawsper 13y ago
    I noticed that they remember that I like SSH-links and now it is always displayed to the right, that is quite nice.
- nunb 13y ago
  Presumably, by the fifth time this happens, it'll be seared in your brain. And the browser url is already prominent.
jomar 13y ago
You can clone with HTTPS, SSH, Subversion, and other methods. Before I clicked "Enable Repository Next" there was also a "Git Read-Only" option. The "other methods" text points to https://help.github.com/articles/which-remote-url-should-i-use https://help.github.com/articles/which-remote-url-should-i-u... which lists HTTPS read-only & read-write and SSH read/write. Last time I looked that page also listed Git read-only (with the description "All git:// URLs are anonymous, public and read-only. Private repositories do not have this URL type. // Use these URLs when cloning someone else's repository (where you don't have write access) and for submodules that point at public repositories."). There was no explanation in the "Repository Next" blog posting that git:// URLs were being disappeared...

by chintan 13y ago

technoweenie 13y ago

The preferred URL is the one in the browser address bar: "https://github.com/{owner}/{repo}" https://github.com/{owner}/{repo}". Works great for pushing and pulling.

dsirijus 13y ago
Yeh, but the convenience of it here is that you may freely browse that repo (and change URL in the address bar), and still have the access to the repo URL.
- jeremymcanally 13y ago
  The clone URL was never accessible from deeper pages.
  - moe 13y ago
    And that has always been a pain in the ass. Github needs to start fixing things rather than constantly making them worse. Whoever is in charge of their UX-design needs to be replaced.
  - dsirijus 13y ago
    I've never said it did. I said how it ought to be.

Legion 13y ago

Agreed. I use Bitbucket every day, and while it's far short of 30 seconds, I do find it takes a second or two of extra scanning to notice where the repo URL is. And it's essentially on the top right, not aggressively out of the way. Now, Github's pushing it even further out of view than Bitbucket's location.

monkmartinez 13y ago

Honest question: Is Github supposed to be about Git and code? Statement of opinion: It seems to me that Github is the leader of online code hosting. However, this position could be disrupted because, and I could be wrong, Github focuses on items not directly related to git and/or code. I dream of a time when the average person making manuals or Stand Operating Procedures in an office environment can see the benefits of source control and has tools that make git easy. The company that truly focuses on making Git itself dead simple and powerful will win. I pay github every month, but I am starting to lose my patience. I am actively looking to support a company that focuses on abstracting the completely unforgiving nature of git. In my opinion, you shouldn't need to be a command line virtuoso nor need to grok the entirety of the git code base to use git. Eventually, everyone gets dirty with git and thats when the lack thought in usability exposes itself. Github could focus on this, but it seems like they have other priorities which is fine. I have mine too.

gjtorikian 13y ago
Do http://mac.github.com/ http://mac.github.com/ or http://windows.github.com/ http://windows.github.com/ not work for in "abstracting the completely unforgiving nature of git"?
- bhauer 13y ago
  They help, but as a user of Github for Windows, I have too often been told that a "synch" (basically a combination of push and pull) failed and I need to resolve the issue using my command prompt. As an anecdotal measure, I would estimate this happens about 5 to 10% of the time while working alongside my colleagues who are not using Github for Windows, or any similar GUI tool, and using our own private Gitlab origin. Github for Windows is also disappointingly lacking in functionality that is necessary in my workgroup. For example, it does not support Git submodules or two-origin configurations. When I work in repositories we have configured in that fashion, the command line is my option of choice. And let me be frank: there are scarcely any tools I use that have a worse user interface than the Git command line tool. I agree with the grandparent that there remains a market under-served: to provide a decent user interface on top of Git. Github for Windows is amazing for a free tool and I give the development team a great deal of respect for what they have provided users like myself (people who want their source control and build tools to just do their job simply and get the heck out of the way). But there is a lot of room for improvement. I for one would pay good money for a Github for Windows "Professional" version.

MattRix 13y ago

Yeah but by the time you've used the site a couple times, you'll be able to find the repo url from then on. It really doesn't make any sense being at the top of the page taking up so much prime space.

simonz05 13y ago

They added a green button which i assume is "fork on github". It seems they want to encourage people to use github rather to clone to local filesystem.

xixixao 13y ago
Nope, that one is for pull requests. But they did disable SSH cloning for read-only and the cloning URL is not showing at all (only after you click on HTTPS), pointing towards preferring of forking.
shardling 13y ago
They've always had a quite prominent "fork on github" button. Their suggested course of action is to fork on github and then clone to your local filesystem. You then push changes to your fork on github, and open a pull request from within their system. The default workflow is designed to play nice with their issue tracker/etc.

kawsper 13y ago

I spend way too long looking for the repo URL. Too bad they have hidden it away, I think it is one of the most used features in a repo.

nunb 13y ago
Presumably, by the fifth time this happens, it'll be seared in your brain. And the browser url is already prominent.
- kawsper 13y ago
  I noticed that they remember that I like SSH-links and now it is always displayed to the right, that is quite nice.
nunb 13y ago
Presumably, by the fifth time this happens, it'll be seared in your brain. And the browser url is already prominent.

jomar 13y ago

You can clone with HTTPS, SSH, Subversion, and other methods. Before I clicked "Enable Repository Next" there was also a "Git Read-Only" option. The "other methods" text points to https://help.github.com/articles/which-remote-url-should-i-use https://help.github.com/articles/which-remote-url-should-i-u... which lists HTTPS read-only & read-write and SSH read/write. Last time I looked that page also listed Git read-only (with the description "All git:// URLs are anonymous, public and read-only. Private repositories do not have this URL type. // Use these URLs when cloning someone else's repository (where you don't have write access) and for submodules that point at public repositories."). There was no explanation in the "Repository Next" blog posting that git:// URLs were being disappeared...