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.
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.
This is probably as a DoS protection; accepting large responses have always been a vector. They could work around this by having some additional logic fire beforehand to prevent it becoming an attack vector.
> (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.
The "repo landing page" is already handled, somewhat, by GitHub Pages—the idiomatic repo setup is to have a GitHub Pages site "about" your software, linked from the description field of the repo; to link Release downloads directly from the GitHub Pages site, bypassing the repo; and to link to the repo from the GitHub Pages site under a "view source" or "contribute" Call-to-Action. The repo itself, with its README.md, then serves just to document the implementation—setup, usage, release notes, etc.—rather than to describe, explain, or teach you how to use the software.
Speaking of GitHub Pages, this feature complements it perfectly. Now you can create a GitHub-powered website—including images et al—without touching git, in much the same way you'd use one of those "FTP web interface" panels on a VPS. Except that each upload becomes a commit, rather than just mutating some ephemeral folder somewhere.
The current landing page format has long been an annoying thorn. Only having a one line summary and URL "above the fold" is a terrible UX for people just arriving at a new repo. I wish they'd add a reactive layout for widescreen displays that shows the README and dev info side by side.
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.
I think sort of the implication here is he's just coded up something that may be a starting point for something that will later involve more files - just makes it easy to do the initial repo setup.
[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.
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.
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.
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.
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.
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:
> Why not work directly in the version controlled cloud?
What do you do if you need to work offline? You are on a plane and forget to sync something, or for whatever reason you can't access to repository (maybe China is DDOSing GitHub again?). This is also one of my main gripes about cloud based editors, it's great if you have internet access but if you don't or you have a poor connection (e.g. public wifi) you are SOL.
I use Write (iOS) and NVAlt (OS X) which sync via Dropbox, so I always have a local copy of my notes.
> no backups to worry about
Please don't solely rely on companies to store your data. They can and do lose peoples files [0].
Real answer, though not who you were replying to: Org mode syntax is more appealing to me, particularly the wiki-style links. I liked it enough to use it before I used Emacs with vim-org but it was lacking so I'm happy enough editing with either Emacs on the desktop, in the browser (Github Wiki), or in Editorial (iPhone). Editorial actually does collapse/expand for Markdown so it would be nice to have that for .org files too, but I would put up with a lot of crap as long as I can work with my files in Emacs 10% of the time.
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.
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.
> 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...
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.
Search/code management metrics are done at the branch level and there will be case-sensitive searches. The indexers are already building case sensitive indexes, it's just that it hasn't been enabled.
Unfortunately I can't say when the indexer will be available for private use at the moment.
Edit:
Forgot to mention that because the indexing is done at the branch level, searching across branches to verify what is/isn't present is pretty trivial like the following example:
I'll return the FYI and let you know it wasn't immediately obvious that there were arrows I could click on to see what else it was your product can do.
Thanks for the feedback. I've had a sneaky suspicion that people weren't really getting a full idea of what the product does. I've been meaning to add more visual cues like dots on top of the image to indicate that there are multiple pictures/feature highlights.
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.
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. :)
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.
Looking through their blog, they had a dry spell from November 16 (release of the new Repository look) to January 27 when they released the new Markdown comment editor. This is, of course, because of the holidays. Then they released the improved GitHub Importer on February 11 and now PR/Issue Templates and File Uploading yesterday and today.
Prior to the repository redesign, they released Git LFS and the Integrations Directory on October 1. So they had a full month and a half between feature releases not attributable to the holidays.
I definitely appreciate the work they've done in the past few months, but I also think it's disingenuous to say that the last month didn't cause them to double down on developing new features.
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.
GitLab has been doing a pretty good job of releasing new features in their monthly updates. [Last month's 8.4 release](https://about.gitlab.com/2016/01/22/gitlab-8-4-released/) has a few nice additions. 8.5 will release on Monday, mostly with a focus on performance improvements, and there are some big ones :) Also a new Issue sidebar design!
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"
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.
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.
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.
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.
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...
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.
Well, the reason I said that is that a year or so ago I set up a gh-pages website for a person who I doubt could tell you what any of those things are. She's done fine so far, except that any time an image needs uploading I have to do it on the command line.
This argument could be made against wikis and issues and static websites (and file uploads).
I think a discussion forum is integral to any open source project. People traditionally use mailing lists, which have an awful UX in my opinion. A moderately better alternative is google groups, which is basically just a nicer UI for a mailing list.
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?
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.
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.
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.
Yeah, this has been the workaround for a while. But when you see users doing stuff like this, it's a pretty strong signal that you need to think about supporting their intention with a dedicated feature.
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.
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.
(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.