
You can now create files on GitHub - geetarista
https://github.com/blog/1327-creating-files-on-github
======
antirez
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.

~~~
timr
_"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.

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

~~~
timr
_"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?

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

~~~
kibwen
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>

------
swanson
Inside a Jekyll repo on Github:

    
    
        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
    
    

If there was a way to do the live markdown preview using the css (maybe you
could inline link it?), then you have a pretty complete blog engine for
hackers. This would be an awesome feature IMO.

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

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

~~~
emillon
There's a "rel=vcs-*" microformat :

<http://joeyh.name/rfc/rel-vcs/>

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

~~~
james33
Cloud9 IDE is actually a very nice cloud-based editor that already hooks into
Github and others.

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

~~~
huskyr
Cool! What are the main benefits you noticed when comparing it to the
traditional offline model?

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

------
hardik988
This is fantastic news. I think this qualifies Github as a complete blogging
engine now, with the plethora of static site generators available.

~~~
thirdtruck
Agreed. I've used it for a blog and a promotional site for a few months now.

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

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

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

~~~
USSRLivesOn
I believe the editor is ACE:

<https://github.com/blog/905-edit-like-an-ace>

<https://github.com/ajaxorg/ace>

------
bryanh
I bet it is very satisfying to just constantly ship cool new discrete features
like this for a product like GitHub.

------
Swizec
This is awesome for drive-by commits of documentation and such. Marvelous.

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

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

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

------
recursive
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!

------
CD1212
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!

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

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

------
RDDavies
This is really wonderful. Great for those of us who work from tablets
frequently.

~~~
mminer
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).

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

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

~~~
briandoll
Gist is great for that too: <https://gist.github.com/>

~~~
kgabis
Also this: <https://github.com/ConradIrwin/jist>

~~~
voltagex_
I wrote one too!

<https://github.com/voltagex/python-gist>

------
obilgic
What about creating a folder?

------
ios84dev
Is it possible to disable this feature so that people can't randomly commit
code to a core repo on a team?

~~~
damncabbage
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> )

------
eagsalazar2
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?

~~~
3825
I assume the push would fail?

------
lux
This is really cool! One tiny feature request: Remember my last settings for
tabs/indentation.

------
gingerlime
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?

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

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

------
isbadawi
I just realized you can edit files. Is that new too? Or is it only the file
creation that's new?

~~~
Timothee
Only file creation is new. I had been wondering where file creation was since
they added editing though. This is very welcome.

~~~
spb
Yeah, how long have they had file editing for? I remember seeing it last year,
and realizing how quickly I'd hit a wall if I couldn't create new files.

