You can now create files on GitHub(github.com)
github.com
You can now create files on GitHub
https://github.com/blog/1327-creating-files-on-github
91 comments
Don't they then need to be able to support mergetool? I mean editing, which this essentially is, seems to open a whole can of worms. What if someone else creates a README and pushes to the same branch while you are in the process of creating a README?
I assume the push would fail?
That's really cool. Would be even nicer if you can upload any file and attach it to a github issue. That's the only thing keeping us from moving our issue tracker to github (private repository). Unless I missed some sneaky way of doing this?
So this means that when github tells you, "We recommend adding a readme to this repo" you can actually do it right there! It's even a link now. Ah this is so great.
Not only is this a great thing (well, everything about github is pretty great) but now I know that the funny icon can be called "breadcrumb".
This is fantastic news. I think this qualifies Github as a complete blogging engine now, with the plethora of static site generators available.
Agreed. I've used it for a blog and a promotional site for a few months now.
[deleted](4)
Inside a Jekyll repo on Github:
Github would then be the place where you put your code, write your blog, track your issues, paste snippets for IRC (Gist), display your business card (profile info), and host your talk slides (SpeakerDeck). The next logical step to me would be integrating conferences/user groups (ala Lanyard/Meetup.com).
PS. @github feel free to hire me to help build it out :P
New file button = New Post (rich editor)
Branch and new file = Draft
Edit button (owner) = Edit
Edit button (reader) = Submit correction
Pull request = Submit Guest post
Pull request comment = Copy/content editor
Issues = Idea/Suggestion bucket
Commit button = Publish and deploy
Github would then be the place where you put your code, write your blog, track your issues, paste snippets for IRC (Gist), display your business card (profile info), and host your talk slides (SpeakerDeck). The next logical step to me would be integrating conferences/user groups (ala Lanyard/Meetup.com).
PS. @github feel free to hire me to help build it out :P
I love this idea for Github and think it would be a really exciting move for them! One thought though - could the Git protocol† for editing, correcting, guest posts etc not also work well as a more general protocol for hacker bloggers?
Something like a meta tag on the index page for the blog, pointing to the git repository‡? (be it on Github, Bitbucket, or your own server) A simple command-line tool (or browser extension) would assist in checking out the repository, and you could issue the pull request with whatever communication protocols you have in common (no need to re-invent the wheel here).
† It needn't just be for git, of course - it could work with many (any?) distributed version control systems (Mercurial and Bazar spring to mind)
‡ I realise you may not necessarily want everyone to have access (even read-only) to your repository - for example, you may have future, draft posts in un-merged branches. The beauty of distributed version control is that there's no canonical server - so there's no reason the public one has to have any branch pushed to it other than master.
Something like a meta tag on the index page for the blog, pointing to the git repository‡? (be it on Github, Bitbucket, or your own server) A simple command-line tool (or browser extension) would assist in checking out the repository, and you could issue the pull request with whatever communication protocols you have in common (no need to re-invent the wheel here).
† It needn't just be for git, of course - it could work with many (any?) distributed version control systems (Mercurial and Bazar spring to mind)
‡ I realise you may not necessarily want everyone to have access (even read-only) to your repository - for example, you may have future, draft posts in un-merged branches. The beauty of distributed version control is that there's no canonical server - so there's no reason the public one has to have any branch pushed to it other than master.
There's a "rel=vcs-*" microformat :
http://joeyh.name/rfc/rel-vcs/
http://joeyh.name/rfc/rel-vcs/
Have you seen Prose? http://prose.io/about.html
Yep - it's the same concept. But native support on Github would be cooler IMO :)
And I believe it has the same issue with live preview not using your own CSS
And I believe it has the same issue with live preview not using your own CSS
There's a /raw endpoint that accepts markdown and renders it - the GitHub for Windows client uses it. Maybe you could use that with some javascript?
How about a browser extension?
This is a great new feature. Another thing this reminded me of is how good the github team is at releasing new features, clearly explaining them, and getting them integrated smoothly and across a wide user base. Its very impressive to me since this is rarely done well IMO.
Finally! I often want to share small scripts and having to create a repository locally first is much less convenient than just pasting the file online.
Gist is great for that too: https://gist.github.com/
It is! And once created, you can push and pull to and from gists just like any git repository :)
Also this: https://github.com/ConradIrwin/jist
I wrote one too!
https://github.com/voltagex/python-gist
https://github.com/voltagex/python-gist
This is really wonderful. Great for those of us who work from tablets frequently.
Agreed. The ability to edit files from the browser made fixing website typos on-the-go trivial, and this gives even more power to developers whose current machine limits terminal access (Prompt on the iPad + a remote server works wonders, but too often I've had only a colleague's tablet or smartphone to work with).
This is awesome for drive-by commits of documentation and such. Marvelous.
Nice to see Github releasing more consumer features lately (deleting branches on merge, now creating files, etc). After not seeing a significant update for months, I thought Github forgot about the consumers in their more focused efforts towards enterprise users.
This is awesome for a number of reasons.
The biggest is probably that you can now have people helping out without teaching them git. Like people helping with translation, they could just copy the original file and translate it locally, then paste it in to a new file. Way cool.
The biggest is probably that you can now have people helping out without teaching them git. Like people helping with translation, they could just copy the original file and translate it locally, then paste it in to a new file. Way cool.
Is it possible to disable this feature so that people can't randomly commit code to a core repo on a team?
Have you tried switching to the fork-and-pull-request model instead of everyone directly committing to the main repo?
(It's how many, many open-source projects run, and GitHub has a good write-up of it here: https://help.github.com/articles/using-pull-requests )
(It's how many, many open-source projects run, and GitHub has a good write-up of it here: https://help.github.com/articles/using-pull-requests )
I think that you have bigger problems if anyone anywhere has commit privileges to your repository. You must trust your commitors. Am I missing something?
Excellent timing. One of the elements on my TODO list was to add the Github API to my app to create files that I can then have the user edit. Now I can just use a link instead.
I get the feeling that the various "online IDE" projects may be quickly superseded. If anyone could pull that off, it's Github - just getting Github integration working is hit-and-miss with most of the others. If it could include some live preview functionality for HTML/CSS/JS for mockups and Markdown for writing, it would quickly become vastly useful.
Does anyone know what text editor they're using? I assume it's CodeMirror, but I could be wrong.
Does anyone know what text editor they're using? I assume it's CodeMirror, but I could be wrong.
I believe the editor is ACE:
https://github.com/blog/905-edit-like-an-ace
https://github.com/ajaxorg/ace
https://github.com/blog/905-edit-like-an-ace
https://github.com/ajaxorg/ace
I think it is a great decision on where to place the create new file button, it seems obvious when you see it but is such a simple solution. Or is it just me?
When I read their tweet I was interested to see how they had integrated it with everything else. Off the top of my head I couldn't think of an ideal place without the whole UX feeling clunky. Well done Github!
When I read their tweet I was interested to see how they had integrated it with everything else. Off the top of my head I couldn't think of an ideal place without the whole UX feeling clunky. Well done Github!
Could this be the eventual IDE in the cloud so many others have failed at? Start with getting everyone's code in the system, get them viewing code in your system, commenting on commits daily, then "hey while you're here, why not just edit the file in this little editor"...fast forward several more iterations/improvements and then you find yourself never leaving the web editor.
Cloud9 IDE is actually a very nice cloud-based editor that already hooks into Github and others.
I've been using it to write production code for almost 6 months now. Over the last month, they've eliminated all the minor annoyances. It's solid and works. I couldn't complain even if I wanted to. The codebase is also very approachable. I needed a feature, wrote it, pull request, and they accepted it.
Cool! What are the main benefits you noticed when comparing it to the traditional offline model?
With a traditional IDE, you have to install it everywhere. With me, that would be a half-dozen computers, with 500MB lost on each one. With Cloud9, it's installed on the server and I can access it anywhere there's a net connection. Updates are centralized, you only need to do it once.
And it's funny, but the IDE is actually more performant in the browser. Well, I was using Aptana before, which is essentially Eclipse and that's known to be slow.
Also, it just feels natural to have your IDE right next to the end product. IDE in one tab, web app in the other.
And it's funny, but the IDE is actually more performant in the browser. Well, I was using Aptana before, which is essentially Eclipse and that's known to be slow.
Also, it just feels natural to have your IDE right next to the end product. IDE in one tab, web app in the other.
In fact, Ace (the Ajax.org Cloud9 Editor) is what Github uses for their file editing interface, so if you're editing files on the site directly, you're already using Cloud9, partially.
I had to use Cloud9 a few months ago to populate a new repo for a small project I wanted to share. With today's changes I wouldn't have needed to use Cloud9. Being able to add files is long overdue and I wonder how much it was to stem the tide of users using third party sites to populate github and thereby becoming entrenched in a development/publishing workflow that only used github as a storage layer and not somewhere where you would spend time or send others to the github website.
Can't upvote this enough. Quite a cool project, open source, runs on Node, and is very featureful.
I most definitely agree. However I don't know how they would go about integrating the IDE while maintaining the healthy git workflow that many have come to love.
[deleted]
mbed.org has been doing this successfully for a few years now. The difference is that it's a compact, tightly integrated IDE for a specific technology (C/C++ embedded development) rather than trying to solve everybody's problem.
And yes, we have integrated version control. Based on mercurial. :)
And yes, we have integrated version control. Based on mercurial. :)
What if the internet goes out?
What if the power goes out? What if your main development PC goes down?
The question is really how often does this happen and how long is it out for. Personally I don't remember the last time my internet was out for more then an hour, and that wasn't even in the last year.
Google Docs must have the same problem, how do they mitigate it?
The question is really how often does this happen and how long is it out for. Personally I don't remember the last time my internet was out for more then an hour, and that wasn't even in the last year.
Google Docs must have the same problem, how do they mitigate it?
Google Drive.
I can see the always-on scenario playing out ok for some (web-developers, enterprise folks etc), but I don't see how the hardcore C crowd and their hyper-customized build farms would gain anything from it.
I can see the always-on scenario playing out ok for some (web-developers, enterprise folks etc), but I don't see how the hardcore C crowd and their hyper-customized build farms would gain anything from it.
Editing on a laptop in an area with no WiFi or an internet connection would prove difficult as well.
Re: Google Docs - you can enable offline editing with Google Docs.
http://support.google.com/a/bin/answer.py?hl=en&answer=1...
Re: Google Docs - you can enable offline editing with Google Docs.
http://support.google.com/a/bin/answer.py?hl=en&answer=1...
Oh well, then my ISP must suck :(
Anyways, I travel a lot with my laptop: and I don't have WiFi connection everywhere I go: that's why I don't "live in the cloud" for now.
Google docs has local storage capabilities, at least with their android versions though I think the web version supports it too.
The "local storage" support in Google Docs Android client is still abysmal. I've more than once gotten network related errors when trying to do stuff to a document that I've explicitly marked as "offline".
Vastly better than before though - their offline support is very new.
Vastly better than before though - their offline support is very new.
You could still use a local copy. DVCS rox.
I bet it is very satisfying to just constantly ship cool new discrete features like this for a product like GitHub.
[deleted]
I'm a little surprised by the unanimous positive response here. Usually any mention of a new GUI for any git functionality gets at least some negative feedback. I count this as progress!
[deleted]
Sorry to be off topic, but does it bug anyone else that the language Github uses for their native client is "Clone in Mac" and "Setup in Windows", as if the name of their client is "Mac" and "Windows", etc. Not only is this confusing, because they're naming the product the same as the OS, but it's also a little insulting because it's almost like saying that the normal command-line Git client doesn't run well on those platforms.
I appreciate that they want to draw attention to their native client product, but I really wish they would give it a proper name so that they don't have use the name of the OS instead.
I appreciate that they want to draw attention to their native client product, but I really wish they would give it a proper name so that they don't have use the name of the OS instead.
These buttons are only displayed for users who have installed those tools. We're not using it as advertisement, we're making it convenient for people who have already installed the tool.
Are you sure about that? I do not have the tool installed (or anything like it, since I use command-line git), but I see the "Clone in Mac" button on every single github repo I view in my browser.
I think it's less about promoting their native client as it is about making Github (and Git) less daunting for command-line-evading users. Just so happens their own client is the most user friendly, but it could have been any other, hence not tying the benefit (cloning in the OS with a click) to the implementation.
YES! This drives me totally nuts because people using their clients never become knowledgeable about how git works making those people terrible to collaborate with. The vocabulary they teach them is just totally wrong.
I can't speak for Windows, but if I click "Clone in Mac", it launches Tower.app. So the label seems apt to me. It's more that the URL protocol that sounds wrong to me (github-mac://??).
Thanks for mentioning. That does actually make it useful.
Github is the ultimate no-bullshit company. Any new announce is about some good feature or small improvement that matters: no annoying things to try to protect the company in some odd way, no greedy tactics to make more money in subtle ways. They are completely focused on their users and their product. I wish more tech companies could follow this example.
"Github is the ultimate no-bullshit company. Any new announce is about some good feature or small improvement that matters"
It's funny that you should say this, because I have pretty much the exact opposite impression. Most of their feature announcements are for dubious changes that don't make my life better (web-based CLI? Stars-vs-followers?), but more to the point, they've left really important things to languish (for example: their code search sucks, and their issue tracking system is just barely usable.)
I don't get the sense that GitHub is rowing in the same direction as a company. Their product isn't improving in any consistent way, and for all of the changes that they announce, I'm having a hard time of thinking of the last one that made a positive impact on my life. Certainly, I've never before needed to create a file in github via the web, and I probably never will.
It's funny that you should say this, because I have pretty much the exact opposite impression. Most of their feature announcements are for dubious changes that don't make my life better (web-based CLI? Stars-vs-followers?), but more to the point, they've left really important things to languish (for example: their code search sucks, and their issue tracking system is just barely usable.)
I don't get the sense that GitHub is rowing in the same direction as a company. Their product isn't improving in any consistent way, and for all of the changes that they announce, I'm having a hard time of thinking of the last one that made a positive impact on my life. Certainly, I've never before needed to create a file in github via the web, and I probably never will.
Well I guess here it is really about tastes because I think the bug tracking system is one of the best features of the site.
The feeling you have of them not moving in the right direction probably is about their development model where internally people think at improvements and submit a pull request or something alike, but I guess they also have some long term projects that try to pursue as a whole.
But well the real point here is that we are talking about different things. I mean, you may not be happy with what they accomplish and I may be happy instead, but the company is in general focused into evolving their product while not annoying users.
The feeling you have of them not moving in the right direction probably is about their development model where internally people think at improvements and submit a pull request or something alike, but I guess they also have some long term projects that try to pursue as a whole.
But well the real point here is that we are talking about different things. I mean, you may not be happy with what they accomplish and I may be happy instead, but the company is in general focused into evolving their product while not annoying users.
"I think the bug tracking system is one of the best features of the site."
It's a fantastic tool for avoiding annoyance with bug reports by losing track of tickets. It's perfect for that.
Seriously, though: any ticketing system that doesn't have a way to assign and sort by priority is just fundamentally broken (and no, tags don't count). But almost everything about the usability of the thing is goofy: bulk updating allows you to inadvertently delete tags (oops! hope you didn't need those!), you can't filter based on assignee, and it's easy to get stuck in a view where managing/filtering tags is impossible, with no indication of how to get to the useful interface again (why do they even have a view like that?)
But truth be told, I recognize that GitHub isn't an issue-tracking tool. That's fine. I have these sorts of complaints about nearly every part of the web interface. It's gotten to the point where I avoid using the web UI whenever possible -- it's just a hosted git repo, nothing more. And given that the product is little more than a UI wrapper around git...well, I feel like these are pretty core problems for a user-focused team. So what are they focusing on, anyway?
It's a fantastic tool for avoiding annoyance with bug reports by losing track of tickets. It's perfect for that.
Seriously, though: any ticketing system that doesn't have a way to assign and sort by priority is just fundamentally broken (and no, tags don't count). But almost everything about the usability of the thing is goofy: bulk updating allows you to inadvertently delete tags (oops! hope you didn't need those!), you can't filter based on assignee, and it's easy to get stuck in a view where managing/filtering tags is impossible, with no indication of how to get to the useful interface again (why do they even have a view like that?)
But truth be told, I recognize that GitHub isn't an issue-tracking tool. That's fine. I have these sorts of complaints about nearly every part of the web interface. It's gotten to the point where I avoid using the web UI whenever possible -- it's just a hosted git repo, nothing more. And given that the product is little more than a UI wrapper around git...well, I feel like these are pretty core problems for a user-focused team. So what are they focusing on, anyway?
This is definitely a taste thing. I've worked with issue systems that support priority in the past and found them frustrating - I much prefer being able to invent my own concept of priority using tags (which is exactly what we've done using GitHub issues). I also find the web UI a joy to use, and frequently refer to it over using command-line or desktop git browsing tools.
I agree that Github offers superb code browsing, and their issue tracker seems to be reasonably usable for small projects.
However, I fear that Github's issue tracker might not work at scale. I closely follow just one "large"[1] project that's hosted on Github; most of the developers on that project are accustomed to Bugzilla. Now I've never even used Bugzilla myself, but here are some things off of the top of my head that I remember them longing for:
1) The ability to attach files to issues.
2) The ability to denote dependencies between issues and generate dependency diagrams.
3) The ability to assign priority to issues (achievable using tags, but perhaps there's some advanced functionality I'm not aware of).
4) Ability for users to vote on which issues are most important.
5) Advanced search options (sometimes just having even basic search would be nice... half the time I have better luck searching their issues via Google than using Github's own search tool[2]).
6) A responsive web front-end.
The reason that they use Github's built-in issue tracker in the first place is because everyone and their mother has a Github account, so it lowers the barriers to entry for filing a bug report. And there's no question that they've benefited enormously from this, and the user-engagement that it enables. But the detriments to productivity are real, and the advantage of Github's network effect hasn't stopped them from repeatedly considering migrating their issues to Bugzilla.
And I don't think it would kill Github to abandon their "tags fulfill EVERY USE CASE" position and bake in some more features for advanced users, especially if they hope to capture a bigger share of the more "serious"[2] projects out there (which would only be to their benefit, considering that "serious" projects are the ones that are willing to buy paid accounts for all the users in their organization).
[1] "Large" in this case meaning: hundreds of Github forks, thousands of Github stars, hundreds of thousands of lines of code, a half-dozen full-time developers, and, most pertinently, several thousand issues (and growing at an increasing rate).
[2] Case in point: I just now tried to search for the issue wherein I offered to do the legwork of migrating their database to Bugzilla should it come to that. The title of the issue contains the word "Bugzilla". The text of the issue itself contains the word "Bugzilla" multiple times. Several of the comments contain "Bugzilla". And yet a search for "Bugzilla" using Github's issue search tool reveals only one issue, completely unrelated to the issue I was looking for.
[3] "Serious" in this case meaning: a codebase with hundreds of thousands to millions of users, dozens of full-time developers, and hundreds of thousands of issues.[4]
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=800000 [5]
[5] Help I've gone mad with footnote power [5]
[6] While you're here, fun fact: I once went looking for the Github project with the largest number of total issues, and here's what I eventually settled upon: https://github.com/mxcl/homebrew/issues
However, I fear that Github's issue tracker might not work at scale. I closely follow just one "large"[1] project that's hosted on Github; most of the developers on that project are accustomed to Bugzilla. Now I've never even used Bugzilla myself, but here are some things off of the top of my head that I remember them longing for:
1) The ability to attach files to issues.
2) The ability to denote dependencies between issues and generate dependency diagrams.
3) The ability to assign priority to issues (achievable using tags, but perhaps there's some advanced functionality I'm not aware of).
4) Ability for users to vote on which issues are most important.
5) Advanced search options (sometimes just having even basic search would be nice... half the time I have better luck searching their issues via Google than using Github's own search tool[2]).
6) A responsive web front-end.
The reason that they use Github's built-in issue tracker in the first place is because everyone and their mother has a Github account, so it lowers the barriers to entry for filing a bug report. And there's no question that they've benefited enormously from this, and the user-engagement that it enables. But the detriments to productivity are real, and the advantage of Github's network effect hasn't stopped them from repeatedly considering migrating their issues to Bugzilla.
And I don't think it would kill Github to abandon their "tags fulfill EVERY USE CASE" position and bake in some more features for advanced users, especially if they hope to capture a bigger share of the more "serious"[2] projects out there (which would only be to their benefit, considering that "serious" projects are the ones that are willing to buy paid accounts for all the users in their organization).
[1] "Large" in this case meaning: hundreds of Github forks, thousands of Github stars, hundreds of thousands of lines of code, a half-dozen full-time developers, and, most pertinently, several thousand issues (and growing at an increasing rate).
[2] Case in point: I just now tried to search for the issue wherein I offered to do the legwork of migrating their database to Bugzilla should it come to that. The title of the issue contains the word "Bugzilla". The text of the issue itself contains the word "Bugzilla" multiple times. Several of the comments contain "Bugzilla". And yet a search for "Bugzilla" using Github's issue search tool reveals only one issue, completely unrelated to the issue I was looking for.
[3] "Serious" in this case meaning: a codebase with hundreds of thousands to millions of users, dozens of full-time developers, and hundreds of thousands of issues.[4]
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=800000 [5]
[5] Help I've gone mad with footnote power [5]
[6] While you're here, fun fact: I once went looking for the Github project with the largest number of total issues, and here's what I eventually settled upon: https://github.com/mxcl/homebrew/issues
I think that the stars vs followers update was far from useless. That improvement was absolutely fantastic.
I (and I assume lots of other people) were following repositories because they liked them, the same way someone might bookmark a page because they liked it. But this meant they got every commit and issue update for lots of projects, which was unnecessary clutter.
Github realized this and made a distinction between liking a repository and actively following its every change.
The stars/followers update says a lot about how good Github is at stepping back and looking at the user experience as a whole.
I (and I assume lots of other people) were following repositories because they liked them, the same way someone might bookmark a page because they liked it. But this meant they got every commit and issue update for lots of projects, which was unnecessary clutter.
Github realized this and made a distinction between liking a repository and actively following its every change.
The stars/followers update says a lot about how good Github is at stepping back and looking at the user experience as a whole.
"The stars/followers update says a lot about how good Github is at stepping back and looking at the user experience as a whole."
Ehh...it says that a lot of github's popularity is amongst people who do things like "following repositories because they like them", without actually being interested in the details of the projects they "follow". (Meanwhile, the rest of us are over here bookmarking webpages with our bookmark button, and trying to use GitHub to write code, and finding the system lacking...)
I've never "followed" a repository, unless I actually wanted to, you know...follow the repository. But you do raise a good point: GitHub lives in this weird hybrid world that's grown well beyond a simple tool for writing code. Nowadays, much of their user base is there because they think it's everything from a social network, to a blog host, to an online resume. It's probably not surprising that they've lost some focus.
Ehh...it says that a lot of github's popularity is amongst people who do things like "following repositories because they like them", without actually being interested in the details of the projects they "follow". (Meanwhile, the rest of us are over here bookmarking webpages with our bookmark button, and trying to use GitHub to write code, and finding the system lacking...)
I've never "followed" a repository, unless I actually wanted to, you know...follow the repository. But you do raise a good point: GitHub lives in this weird hybrid world that's grown well beyond a simple tool for writing code. Nowadays, much of their user base is there because they think it's everything from a social network, to a blog host, to an online resume. It's probably not surprising that they've lost some focus.
> it says that a lot of github's popularity is amongst people who do things like "following repositories because they like them"
Yes, why not? I'm happy to star the repo which has the code my phone is running, just for later references. It might be far from the most useful feature at github, but what does it tell about me? Why are you being mean, if I may ask?
> Meanwhile, the rest of us
You and parent and maybe grand parent use this "rest of us". What does it mean? That you need to bring with you the "rest of us" (your team, your friends?) to make a point.
Mind you, under the hypothesis I understood it properly, I actually agree with your core point, which is that github is sometime giving the impression to feed the crowd with new features that are a tight bit superficial.
But this point is 98% uninteresting if you don't bring a laundrylist of mind-breaking feature you think should be coded instead. I'll help with a few:
- Commit forwarding to same repo at other hosts
- Use github as git-svn interface
- Private repos (I seem to be the only one to not want everyone to peek at my shitty hardcoded bashrc)
- Shared repo templates (eg create a new repo with a python gunicorn setup ready made, after filling a few fields), a la Linode recipies
- Allow-all repos, anyone can commit to it.
- Shareable user created repo analysers, code checkers, commit hooks.
I have no idea if any of these ideas is sane, but at least it should leave a bit less negative trails on this board.
Yes, why not? I'm happy to star the repo which has the code my phone is running, just for later references. It might be far from the most useful feature at github, but what does it tell about me? Why are you being mean, if I may ask?
> Meanwhile, the rest of us
You and parent and maybe grand parent use this "rest of us". What does it mean? That you need to bring with you the "rest of us" (your team, your friends?) to make a point.
Mind you, under the hypothesis I understood it properly, I actually agree with your core point, which is that github is sometime giving the impression to feed the crowd with new features that are a tight bit superficial.
But this point is 98% uninteresting if you don't bring a laundrylist of mind-breaking feature you think should be coded instead. I'll help with a few:
- Commit forwarding to same repo at other hosts
- Use github as git-svn interface
- Private repos (I seem to be the only one to not want everyone to peek at my shitty hardcoded bashrc)
- Shared repo templates (eg create a new repo with a python gunicorn setup ready made, after filling a few fields), a la Linode recipies
- Allow-all repos, anyone can commit to it.
- Shareable user created repo analysers, code checkers, commit hooks.
I have no idea if any of these ideas is sane, but at least it should leave a bit less negative trails on this board.
"Private repos (I seem to be the only one to not want everyone to peek at my shitty hardcoded bashrc)"
GitHub has private repos. You pay for them. It's how they make money.
GitHub has private repos. You pay for them. It's how they make money.
Star-vs-watch is very useful, actually.
One of their advantages is that they're not dependent upon advertising money
Well, I guess they decided to follow this route. For example github receives a very important amount of traffic targeting accounts that are completely free. Even a very small textual AD adsense-style could mean a lot of money. But they don't do it.
sourceforge.net went with constantly more and more annoying advertising because its customers were advertisers, while github.com makes better and better tools because its customers care about managing their source code.
I just realized you can edit files. Is that new too? Or is it only the file creation that's new?
Edit is old - you could do that a while back
What about creating a folder?
Ha, I just requested that two weeks ago via their feedback page. They didn't really told me that they were so close to implement that.
Now I'm still missing to configure the default settings of the builtin editor.
Now I'm still missing to configure the default settings of the builtin editor.
This is really cool! One tiny feature request: Remember my last settings for tabs/indentation.