Upload files to your repositories

[johnloeber]

I think this is a great step, for several reasons -- both corporate and user-facing.

(1) It is true that this is more likely to turn GitHub into a generic file-dump place similar to DropBox. GitHub's infrastructure is sufficiently good to handle this, and this new addition is unlikely to disrupt the workflow of veteran users. However, since it is likely that some companies will use GitHub for file dumping, GitHub will be justified in charging companies a fee for particularly large repositories -- capitalizing on the file-dumping. I sense an alternate revenue stream coming in for GitHub.

(2) I've often run into situations in which I had written a small script and wanted to quickly turn that into a GitHub repo. To do so, I'd have to go through the online interface to initialize a new repo, and then make a folder on the command line, type a few commands, etc. Though it's a very short process, I couldn't understand why I couldn't just use the online interface to type up a readme and then drag-and-drop my script into the repo. The update smooths this work experience.

(3) Obviously, it'll make GitHub far more accessible to less technical users -- some users are intimidated by the Git learning curve, and this update makes them much more likely to use GitHub (and then slowly learn the ropes of using it via the command line).

(4) By inviting more non-technical users as in (3), it becomes more likely that (1) succeeds.

[gechr]

With regards to (1), being a file-dump place: it's worth noting that GitHub currently imposes soft (50MB) and hard (100MB) size limits per single file[1]. If you try to push a file that exceeds either of these limits from the command line, you'll receive a response from the remote server pointing you in the direction of their Large File Storage (LFS) service[2], which they charge for beyond the free 1GB storage/bandwidth per month.

Out of curiosity, I just tried uploading a file larger than 100MB to test the limits via the browser and received the following error:

  Yowza, that’s a big file. Try again with a file smaller than 25MB.

For me, this significantly limits its feasibility as an alternative to Dropbox.

[1] https://help.github.com/articles/conditions-for-large-files/

[2] https://help.github.com/articles/billing-plans-for-git-large...

[sdesol]

> (3) Obviously, it'll make GitHub far more accessible to less technical users

I'd have to imagine this is probably the main driving factor. As GitHub tries to make further inroad into Enterprise, I can see them focusing more and more on making things more accessible to non programmers (project managers, secretaries, etc.)

I really won't be surprised if 5 or 6 iterations down the road, you'll have the option to change the repo landing page. For example, instead of showing the files in a repo, you'll just see the README markdown file. And before you know it, they (GitHub) will start marketing GitHub Enterprise as a competitor to Confluence and other wiki/document management system.

[bitshiter]

regarding point (2) I feel like https://gist.github.com/ fulfills that requirement.

With a gist you're able to quickly and easily upload a single file script (or multiple files).

Also once created you can clone it as a git repo and make updates and push back to it (e.g. add files etc). Also people can fork your gist just like git repos.

I like this approach rather than creating a "new repository" on github for small scripts or snippets because then your github profile doesn't get cluttered with small snippets and script repos and is reserved for actual "project" repos.

[YPCrumble]

[Hub](https://hub.github.com/) is a great little tool for simplifying (2). Initialize a local repo with `git init`, make an initial commit, and `hub create` sends it to GitHub and creates the repo for you.

[GreaterFool]

Right, because Dropbox is so hot right now as a company and a business. Meanwhile, Atlassian's IPO went very well. Even though I hate JIRA I understand why many people need it. GitHub offers nothing on the project management layer and turning GitHub into generic file-dump is a good way to kill the company. GitHub needs to offer project management on top of git, not silly WYSIWYG features.

[minimaxir]

This feature has interesting synergy with GitHub Pages, where .md files can simply be dragged-and-dropped into a folder to get published as a blog post on the web.

It may be enough to remove the must-be-programmer-who-understands-git barrier to entry, anyways.

EDIT: GitHub Pages still requires specific file naming for posts and YAML front matter, so it's not perfectly non-programmer friendly. It might be a good idea to write a tutorial as a blog post/screencast, though.

[lips]

Honestly, I think further development on prose.io UX and functionality is maybe a shorter path past the git barrier. If default branches could be set, new files were based on templates, and YAML presented as form fields, etc. Combined with drag-drop file or image addition, that sounds promising. Yes, detail/devils.

[melling]

You mean .org files, right? :-)

I keep notes on Github that never touch a filesystem. I do my edits from a phone or tablet. If I have a lot to write, I'll use an app then copy directly into Github. Most of my notes are personal but I started breaking them out a couple weeks ago so I could keep them in public repos.

https://github.com/melling/ErgonomicNotes

https://github.com/melling/EditorNotes

Why not work directly in the version controlled cloud? Books, blogs, etc could be managed this way. No proprietary formats, no backups to worry about, and you aren't going to lose it if someone steals your device:

http://www.nydailynews.com/entertainment/tv-movies/francis-f...

[whorleater]

This is actually a pretty good step. Most programmers are already using some kind of UI/command line to push to Github, but having a simple drag and drop for uploads will get those who are less technically inclined on our teams to actually use version control more. At least I really hope I can stop dealing with the "asset_1", "asset_1-2", "asset_1_USETHISONE" that some people do.

[hire_charts]

The problem is that this kind of workflow -- where someone iterates through multiple versions of a file or folder, renaming them each time -- results from the work they are doing offline and the lack of offline version control usage. Adding a step where you drag and drop your iterations into a website might only add to the confusion, rather than actually alleviating that pain.

[SmellyGeekBoy]

> At least I really hope I can stop dealing with the "asset_1", "asset_1-2", "asset_1_USETHISONE" that some people do.

My personal favourite is "asset_1_$TODAYSDATE", where $TODAYSDATE is inevitably in DDMMYY format and therefore completely useless as far as sorting is concerned...

[cdnsteve]

All I want is a Wiki search.... pretty please. Wiki file uploads (images) at very minimum that aren't commited to git. The process now is to create an empty issue, drag the file over, copy the URL and paste it into the Wiki page.

[smoser]

Why not ditch the Gollum wiki and just use the main git repo with relative links? It also renders markdown files. https://github.com/blog/1395-relative-links-in-markup-files

[adregan]

I'd love to be able to search in branches. Especially on projects that commit to master and have release branches when they are between releases.

[ErikRogneby]

Has anyone seen a way to disable this feature at a repo or org level? I'm not crazy about master getting treated like Dropbox.

[munificent]

> Has anyone seen a way to disable this feature at a repo or org level?

Don't hand out commit rights to people?

[wise_young_man]

It's not exactly like Dropbox though, you still have to commit (with a message) similar to how editing a file works.

[tlrobinson]

To clarify, by "upload files" they mean adding and committing new files to a git repository. At first I thought there was some other way to add files to a project.

[douche]

Hmm, it almost seems like the recent brouhaha lit a fire under GitHub...

[gjtorikian]

That's a false assumption. Features like this one take months to get right -- from design, to ops, to engineering, to support, to marketing, to many more.

Saying nothing never meant we weren't doing anything. It meant we could've been better saying something. :)

[emehrkay]

I've always been impressed with how often they release new features, it actually seems like a weekly thing for GitHub. I don't think that the events of the past two weeks accelerated that process at all.

[giancarlostoro]

I was thinking the same thing. It is good to see GitHub get new features, hopefully the competitors do as well. As long as we don't end up with another SourceForge at any point, one is enough.

[juandazapata]

I like how Github is taking note about the lack of innovation, and doing the right thing; but I'd like to see the blog post announcements AFTER the feature is implemented. It's like saying "Oh, you're thirsty? I'm going to give you a glass of water, but not yet, next week"

[arscan]

The feature is definitely implemented as it has been available to me for about a half an hour. Apparently it will just take a little while to roll it out to all users.

[davnicwil]

That would obviously be ideal but announcing after the feature is implemented may be too late.

Opinion shifts have a lot of momentum - let's say promising a feature pushes back on that shift with force X. Announcing the feature when it's live and ready to use pushes back on that shift with force Y. Even if Y has much greater magnitude than X, it is likely much more effective to reverse that opinion shift by applying X today, than Y in a week, or two, or four, when the shift has gathered sufficient momentum that Y has no effect.

[yolesaber]

I see a file upload banner when I look at my repos. Probably A/B testing

[bhalp1]

I would think that this sort of feature was underway well before most of the negative feedback came in. This might be the reason they announced the feature before it was live though.

[brianclements]

Might be a way to get unofficial feedback from the community as the news spreads and make final tweaks before they release it.

[sergiotapia]

Works on some of my private repo's. It's being rolled out probably.

[kjaer]

This is already available to me at least, so the blog post is very welcome.

[petetnt]

This new feature makes it quite easy to use a GitHub repo as a generic file dump / share place.

[fiatjaf]

Which may cause the ruin of the platform.

[kekub]

Finally you can have all kinds of creatives using github without telling them how to use the command line or even the github desktop apps. Thank you github.

[milge]

Github has needed this for awhile. I was using Cloud9 for awhile to push changes to github when all I really wanted was this feature.

[djadmin]

Can anyone explain what's going on here https://github.com/wardowsmcc/badass ?

[r0m4n0]

Awesome... I can think of 4 or 5 times I have been away from my laptop but still need to update a photo for a client. Glad to see this, otherwise I would have never known it had been added!

Slightly brings up an interesting point. With native apps, I usually review release notes upon updating. Webapps get to release whenever they please to little notice of the end user (for better or worse). With releasing new webapp functionality, bug fixes, etc "continuously" I think some cool bits get overlooked...

[roblabla]

GitHub has a pretty extensive changelog in the form of blog posts. They also put them on the github.com homepage, top right (the broadcasts).

It's true that every webapps don't do that though, and that's a real shame for the "power users".

[softawre]

Trello does this well, they put up a "What's new!" banner that presumably marks a cookie or localStorage so you don't see twice.

Quick summary of features and a link to a blog post or release notes.

[Joeboy]

Github pages is now the right way to set up a reasonably-smart-n00b-editable website, IMO.

[nilved]

Maybe for a Hacker News n00b, but a garden variety n00b has not heard of Markdown, YAML, or, for that matter, GitHub. They're going to keep using WordPress, Tumblr and Squarespace.

[hasenj]

Why doesn't github have a proper discussion forum per project? I don't consider the "issues" a proper discussion forum.

That seems to me like it would be much more valuable, specially for community projects.

[derefr]

Presumably because discussion forums aren't anyone at Github's expertise. They're a whole product of their own.

[dogweather]

I'd really like to know the inside details: what changes have they made to release new features quickly like this? Have they been bogged down in process? Or just lack of pressure to release improvements?

[baristaGeek]

Already tried it, and I absolutely love it!

It was something we were waiting for for a long time. Now GitHub is light years ahead of its competitors because of this -seemingly small, but actually important- UX change.

[rwinn]

I'm a bit confused, this is a simple git add or some sort of integration with git lfs they released last year?

https://git-lfs.github.com

[yoavm]

It's just a web interface to git add.

[soyuka]

https://twitter.com/vvoyer/status/700575291433836544 this

[krisdol]

Just to be clear, this appears as if it's some kind of web wrapper to `git add file.ext && git commit -m "<my message>" && git push`?

[hasenj]

It's more like the "edit file" feature where you can edit in-place on the github web interface directly.

It makes github a more complete "gui" for git.

To be honest I don't feel that this is the right approach. But I'm a technical user so who knows. But it feels like github is forking off to a different direction.

Probably trying to look more "inviting" to corporate users; companies where sales are determined by non-technical managerial users. I can easily imagine such types asking questions like: "I want to upload a file to my team's repo, how can I do that?".

It would make it way easier for non-technical users to mess up the repo with tons of binary files, like images, movies, word documents, and excel sheets.

[imron]

You'd be surprised how many people struggle with understanding and doing what you just wrote (and even in knowing that's what they need to do).

[nibs]

Fun fact: you can hack this right now by dragging and dropping a file (ie. image) into the issues submission box and then using that URL in your code to display images.

[ChristianBundy]

I'm confused, haven't you always been able to do that? The issue submission box has always allowed image uploads.

[bluedino]

Wait, so you couldn't add a file via the web before? I haven't used github except for pulling the source to projects but I would expect this was feature #1.

[im_the_internet]

Well as it's based on git, before you just had to push it via the command line.

[beeforpork]

Upload from the browser? O tempora o mores!

[ocdtrekkie]

As someone who makes a lot of casual edits via the web interface, I was really sad that to fix an image file once, I had to install the desktop client and clone the entire repo. This is a great change.

[UncleSam]

This is awesome! I was just barely wanting to upload a file to one of my repositories, but I didn't feel like cloning it to this computer.