What other ones should there be? Mediawise, seems like video-attachments are too rare to develop an inhouse viewer solution for. For binary types...why would they need to be viewed inline?
I was thinking of non-media files - arbitrary files. PDF, docx, odf, txt, etc. The lack of being able to attach arbitrary files to Issues is awkward. That said, for open projects, I can see them wanting to avoid becoming an accidental free file-hosting service.
Those would be useful but I guess in terms of issue-reporting, screenshots are universally valuable for showing erroneous program behavior...when would other filetypes be useful for that, except in cases of programs that are designed to output such filetypes (attaching an ODF would be useful for an ODF generator, for instance)?
Not just outputs, but also inputs. As a hypothetical example, if I had a project that processed MP3 files, and it had bugs on certain files, it would be nice to be able to attach the MP3 files that triggered the bugs to an issue.
Would it not be useful to have test cases covering the broken behaviour (making it not specific to the issue, but rather stuff you could add in a commit)?
We're talking about issues reporting here, if there's a bug with a file being able to include the file itself (by the original reporter or somebody else) is valuable.
That's not super obvious or convenient for new or casual users. You could make the same argument about images; Just make a new repository (or gist) and put an image in it, then link to it!
Since there are no organization private gists [1] you can't use that method for private repositories.
[1] A gist can only be "private" in the sense that it's not listed on the public gist page. No access control takes place once someone guesses the url. That's probably good enough for most uses, but not for all.
Only for applications that don't deal with binary data. The company I work for uses ODF, PDF, DOC and other formats regularly and the inability to attach those files to GitHub issues is a monumental PITA.
With Skitch completely screwing their latest release, hosting issue related files (screenshots, doodles...) was painful to say the least. Dropbox did an ok job at it but did not let me embed pictures in the thread (the file URLs change randomly).
Pretty awesome that the guys at Github got that covered.
I would love to hear why the github team waited so long to bring this feature into existence? I am sure there is a good reason (or maybe not) but it would be awesome if a member of the team would stop by and post the details.
We don't have roadmaps or a prioritized backlog, so we weren't exactly "waiting" to implement this. Someone got fed up with the image workflow, figured out a solution, grabbed some other people to help, and shipped it.
Someone came up with a design. Someone else implemented the backend. We iterated on it for a bit and shipped it internally. Then we figured out the CDN situation, setup logging and metrics, and shipped it genpop today.
Now I know github doesn't have a typical roadmap or backlog but I guess what I was looking for was how someone decides what feature they are "fed up" with not having.
We use GitHub to build GitHub, so typically a feature comes from our own usage pain points.
I imagine the conversation internally went something like, "Man, attaching an image to an issue is really annoying. Let's make it not suck." An issue and pull request followed, internally shipped it to test it, and today rolled it out to you all.
That's literally how 99.99% of features happen on GitHub. :)
I was working on a project where, when viewing an issue, you could use the file picker to choose a file that was then committed on the project's 'gh-attachments' branch, and then linked via markdown to the raw URL.
In a perfect world: the next release (usually a few months apart). But software has a way of coming up with unexpected problems, so let's call that a goal :)
We've spent a lot of time this year ensuring Enterprise has feature parity to every new feature we ship on dotcom, and this was no exception.
Seemed like the perfect balance between, hard enough that you don't throw everything on there and eat up space, but useable enough that it works fine when you need it.
Nothing! In fact, the new issue attachments code uses plain ol' Markdown to show the image. The reason we added this is because arcane Markdown code is impossibly hostile for new users and beginners.
Have you ever had a manager/user/whatever person issue a screenshot of an issue using markdown? It doesn't work. Github is supposed to be for teams too (private repo's), and this brings it 1 step closer, but still far from what other services offer for issue tracking.
1) Hard to use for mere mortal users (QA, testers, normal users posting issue for an App, etc. 2) If uploaded to another site, the images are under a different protection domain (for protected repositories.)
I've been trying to get our QA team to switch over from Bugzilla to GitHub for months and their only hold-out was that you couldn't add images. FINALLY! This is awesome!
I find the lack of ticket features in github has been the biggest blocker. Doing any reporting, or saved searches on github issues requires custom tooling.
I've been trying to get our QA team to switch over from Bugzilla to GitHub for months and their only hold-out was that you couldn't add images. FINALLY! This is awesome!
Oh, by the way, people were asking on Twitter, so we just enabled support for the HTML5 clipboard API. If you're using Chrome, you can now just paste an image into the comment box to upload it!
Very handy with Mac OS X screenshot shortcuts that copy straight to the clipboard.
I always reverse the shortcuts to that copy is:
command + shift + (3/4) and save file is command + shift + control + (3/4)
Some other os x screenshot tips:
- hold space while dragging a selection and you can reposition the selection's origin
- press space to switch to window capture mode. This captures the whole window even if it is obscured.
Fun fact up until recently (mountain lion I believe) the capture window icon was a holdover from NeXT. I wish they'd left it alone, the new one isn't nearly as cool :)
Glad to see they're working on parts of the product that affect developers again.
Now, if they'd add sortable ticket priorities, fix the janky UI problems (like the thing where you can get stuck in the useless view where tags aren't selectable), and add other basic features like ticket up-voting and support for teams, it might become a genuinely useful tool for non-toy projects.
As a source repository its more than useful for non-toy projects from my experience. While the issue features a bit lacking when compared to full blown ticket trackers, the pull request feature is brilliant. I've yet to see another tool that makes code review and collaboration as simple and flexible as github's pull requests.
73 comments
[ 3.0 ms ] story [ 133 ms ] threadThis new way is much better.
[1] A gist can only be "private" in the sense that it's not listed on the public gist page. No access control takes place once someone guesses the url. That's probably good enough for most uses, but not for all.
Pretty awesome that the guys at Github got that covered.
Hosted all of my images for our GitHub Game Off entry[1] README file there. Always a solid solution if you want any sort of image hosting.
[1]: https://github.com/TARGS/game-off-2012
http://imgur.com/faq#long
'Cloud', an App, has been a decent workaround for this problem but in-ticket file uploads is better yet.
Now if they could only fix their damn search! :)
http://searchco.de/?q=irq_create_mapping+url%3Agithub
Its not the full index of public repositories though as I don't have a hook into GitHubs project feeds like I do for Codeplex.
It's one of the main reasons we've switched from Acunote to Trello.
I imagine the conversation internally went something like, "Man, attaching an image to an issue is really annoying. Let's make it not suck." An issue and pull request followed, internally shipped it to test it, and today rolled it out to you all.
That's literally how 99.99% of features happen on GitHub. :)
This is good enough for me :)
We've spent a lot of time this year ensuring Enterprise has feature parity to every new feature we ship on dotcom, and this was no exception.
The best answer is: when it's ready, but not before.
Meme freely!
Damn useful, I have to say. Thanks our friends :)
I'll take the downvotes. it was worth it
Also the top post in this article is just someone calling this a "Christmas present"; at least you made me chuckle.
Seemed like the perfect balance between, hard enough that you don't throw everything on there and eat up space, but useable enough that it works fine when you need it.
Very handy with Mac OS X screenshot shortcuts that copy straight to the clipboard.
(Windows has built-in shortcuts to screenshot to clipboard too: PrtScr grabs the whole screen, Alt+PrtScr grabs just the active window)
Some other os x screenshot tips:
- hold space while dragging a selection and you can reposition the selection's origin
- press space to switch to window capture mode. This captures the whole window even if it is obscured.
Fun fact up until recently (mountain lion I believe) the capture window icon was a holdover from NeXT. I wish they'd left it alone, the new one isn't nearly as cool :)
Now, if they'd add sortable ticket priorities, fix the janky UI problems (like the thing where you can get stuck in the useless view where tags aren't selectable), and add other basic features like ticket up-voting and support for teams, it might become a genuinely useful tool for non-toy projects.
This I guess is the UI release