Hacker News Reader

Comment by chintan | Hacker News Reader

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.

View on HN

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.

Do http://mac.github.com/ or http://windows.github.com/ not work for in "abstracting the completely unforgiving nature of git"?

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.

Try Atlassian's SourceTree.[1] I have only used the Mac app. It's the GUI I settled on after trying three or four others, including Github (again, for Mac). They built the Windows client after everyone who uses Windows at work clamored for it. I'm still on XP though and it requires 7+.

Atlassian also has a good, friendly set of tutorials for using Git.[2] The order in which they introduce the concepts and the commands encourages a clear understanding of the whole system.

[1]http://www.sourcetreeapp.com/ [2]http://www.atlassian.com/git/tutorial

SourceTree has been great and Atlassian's support is also excellent. However, I still can't work out how to turn off Git's overly-optimistic automerge, which leaves << HEAD strewn through files at random.

Using the command line, that would be a merge conflict. If SourceTree is treating it as a successful merge, that would be a bug.

I briefly tried SourceTree when the Windows build was first made available for download. However, it too did not support Git submodules--although from my understanding the Mac version does. I'll keep an eye on it though, since that seemed like something that would be added in time.

I am a firefighter and hobby/part-time developer. We have more manuals and SOP's than you can shake a stick at. They should be in source control so we can see how strategy and tactics evolve over time, who made the changes, diff's and/or allow "pull requests" from the field to change something for the better, as just one example.

Now, try to explain to your Chief or supervisor about how awesome Git is.. that is easy and I've done it. Then comes the part where you explain how to use it; The problem is the interface on both the CLI and GUI require a TON of "other" domain knowledge to use effectively. Abstract all that away at the same price point of Github and you will win a HUGE market.

We don't have IT budget to pay anyone to do this... nor buy the extremely expensive solutions that already exist. So we rely on email and ad hoc training to make sure everyone can stay abreast. Now, how many businesses not related to software development could benefit from Git or a similar DVCS?

That's a pretty interesting use case. I'm always interested in occupations with non-technical emphasis that are moving towards Git, GitHub, and source control in general.

I'd be really interested in hearing more about the problems you face, personally and within the firestation. If you'd like you can email me at my username [at] gmail.

Will do. Think about medical records or 911 call data in a git repo. This is evolutionary stuff that no one in the fire service is thinking about. Hell, our IT guru's can't seem to get clean data from one database to another. Its a sad state in .gov IT at the local level.

We used MS word with revision tracking on my VFD. Of course if the file is lost or corrupted- out of luck.

Have you all tried using some of the features built in to the editors like revision tracking or history a la google docs?

I know I'm starting to go apples to oranges here- but just tossing that out since those features are sometimes overlooked or forgotten about.

Hello Brother! Yes, we've used those... sadly they don't work "at scale." My department has 600 members and a lot of them have good ideas. They have to go through the chain-of-command to get those ideas heard. This method not only suffers from the telephone problem Ie. the idea is lost in translation. It also suffers from a Chief or Capitan not liking the idea(s) and never doing anything with it. Manuals and SOPs in a democratic environment where anyone could clone, make changes and submit pull-requests would be a manna from heaven.

In that case a Github wiki might be a good start. You get the version control, but there's enough abstracted away that it should be easy to get up and running with. Now, you just need everyone in your department to get a Github account...

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

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.

The clone URL was never accessible from deeper pages.

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.

I've never said it did. I said how it ought to be.

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-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...

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.

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.

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.

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.

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.

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.

Presumably, by the fifth time this happens, it'll be seared in your brain. And the browser url is already prominent.

I noticed that they remember that I like SSH-links and now it is always displayed to the right, that is quite nice.

Reply on news.ycombinator.com