Upload files to your repositories(github.com) |
Upload files to your repositories(github.com) |
(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.
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.
[1] https://help.github.com/articles/conditions-for-large-files/
[2] https://help.github.com/articles/billing-plans-for-git-large...
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.
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.
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.
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.
My personal favourite is "asset_1_$TODAYSDATE", where $TODAYSDATE is inevitably in DDMMYY format and therefore completely useless as far as sorting is concerned...
Don't hand out commit rights to people?
Saying nothing never meant we weren't doing anything. It meant we could've been better saying something. :)
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.
You can see [the Changelog](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO...) for more information.
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.
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...
It's true that every webapps don't do that though, and that's a real shame for the "power users".
Quick summary of features and a link to a blog post or release notes.
That seems to me like it would be much more valuable, specially for community projects.
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.
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 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.
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...
Specifically, my method involves using drag-and-drop .md files for the Jekyll workflow.
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].
[0] - http://www.zdnet.com/article/dropbox-sync-glitch-results-in-...
So the .md is technically more correct. But really the extension doesn't matter much...
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.
For example, `markdown inline code` vs ~org-mode inline code~, and
```
markdown code blocks
```
#+begin_src
org-mode code blocks
#+end_src
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.
What's wrong with separating the descriptive text from the images, and making people scroll down to read more?
