I'm looking for a view where I can see quickly which repos I have locally stored in a folder and what each is for. I know I can add details to the README, but the description would be a good place to put a short blurb to remind me of the purpose of each repo without having to drill down into each one. Something similar to what is available on the GitHub website makes sense to me. I'm using GitHub Desktop and haven't seen anything within it, but if another app has this functionality, that could also work.
I want to update Topic/page titles on my GitHub wiki (which is currently using Markdown syntax). When I do that using the GUI it renames the Markdown files, and breaks all of the links.
I know that I can rename the Topic files in the Git repository and push the changes, but that doesn't help the broken links.
Is there a way to avoid this, and make GitHub Wiki's behave more like other Wiki products? I could not find an better way on GitHub documentation.
Welcome to StackOverflow. As best I can determine you cannot rename a GitHub Wiki page without its markdown file also being updated to the new name. The two are tightly coupled.
This Web Applications (StackExchange) Question has some alternatives you may consider, i.e. instead of renaming the page, create a copy. Then edit the original page so that it directs visitors to the new page via a link. This way the original page link remains valid but directs visitors to the new page.
I'm trying to purely use the website Github to create a repo, then public first commit. (Because I cant install the desktop client on this computer, nor use the command line, school restrictions)
I found a little cheat, I clicked the "make readme" button then renamed that file to make the first commit.
I created a screncast here:
Youtube :: Use Github without the Desktop App
After that I can create new text based files by clicking "+" button and create subdirectories too. But I don't know how to upload image, other text based files, or other non-text files to the repo using just the website. Does anyone know?
GitHub's web interface isn't designed as a complete Git solution. It allows you to do a subset of the operations you could do in a local clone, including just about every part of GitHub Flow.
Their documentation about adding files only covers adding text files using the online editor, which you have already discovered. I don't believe that it supports uploading files.
[[Please note that Github has changed a lot since this question was first asked; instead of "download page" read "new release".]]
I generate PDF documentation as part of my projects and I'd like them to stay in sync with my Git repository (it's not always possible for people to build their own since they often use proprietary fonts).
However, it's not really "correct" to add the PDFs to the repository since it's a derived file; furthermore, doing this adds significantly to the size of the commits and the size of the repository overall.
Is it possible to programmatically send files to the GitHub download page? (I know that tagged commits are automatically added there with git push --tags but I don't know where this is documented. I suppose I could do something fancy by adding a separate branch only containing the PDFs themselves — as done by the GitHub user pages — but I'm a bit rusty on using Git this way.)
Github API v3 supports this feature.
GitHub also provides a maven plugin based on the java API that is part of the Eclipse Mylyn connector for GitHub.
There is a ruby gem called github_api.
The other answer talks about net-github-upload which is available for perl and ruby.
check out for net-github-upload which is available
for perl: http://github.com/typester/net-github-upload-perl
and ruby: http://github.com/Constellation/ruby-net-github-upload
With that you can write a small script to upload and update your PDF easily. To sad there's no easy way provided by github guys themselves..
cheer!
The GitHub blog post announcing that this feature has been disabled: https://github.com/blog/1302-goodbye-uploads
I take it that by "GitHub download page", the owner means a repo–more specifically a branch– that can be downloaded via the "download" button.
If you want to add a file to a repo using the API, you will have to become familiar with the process described here: https://developer.github.com/v3/git/
It's not the easiest process in the world, but mastering it will force you to understand the concepts of blobs, trees, commits and references, amongst others.
You can't just "send a file" to a repo because you're working with Git, and Git has some "internal expectations" that you just can't ignore (it's impossible to think of GitHub as some sort of host that you can ftp). Explaining the flow required to create a file in a GitHub repo is certainly beyond the scope of the original question, but to provide a clear answer: no, it's not possible to programmatically upload a file on GitHub, but yes it is possible to programmatically push a file on GitHub".
There's a PHP library named GitHubTreePHP that lets you automate the process (Disclaimer: I wrote it).
I have a simple blog application written in Python, using Django. I use Git to version-control this website. The main content of the site is a blog. The blog entries are stored in a SQLite database (which is not version-controlled, but is backed up regularly); some entries contain images and other media (like PDFs).
I currently store this "blog media" in the repository, alongside other media (such as external JavaScript code, and images used for layout purposes -- all nicely organized, of course). It occurred to me, however, that this isn't really a good strategy, for a few reasons:
Whenever I post a new blog entry that contains an image or a link to a PDF, I have to add the image to the repo and then copy a new version to the production server -- which seems like a lot of work just to add an image. It'd be easier just to upload the image to the server (and make a local backup, of course).
Since this media is content rather than code, it doesn't seem necessary to store it alongside the code (and related style media) itself.
The repo contains a lot of binary files, which increase the overall size of the repo; and more importantly,
I never really edit these images, so why keep them under version-control?
So I'm considering removing these files from the repo, and just copying them to a directory on the server outside of the directory containing the Python code, templates, style sheets, etc., for the website.
However, I wondered: Is there a "best practice" for dealing with content images and other media in a website's repo, as opposed to images, etc., that are actually used as part of the site's layout and functionality?
Edit
To elaborate, I see a difference between keeping the code for the website in the repo, and also keeping the content of the site in the repo -- I feel that perhaps the content should be stored separately from the code that actually provides the functionality of the site (especially since the content may change more frequently, and I don't see a need to create new commits for "stuff" that isn't necessary for the functioning of the site itself).
Keep them in version control. If they never change, you don't pay a penalty for it. If they do change, well, then it turns out you needed the version control after all.
Initially, I would say don't put them in the repo because they'll never change but then consider the situation of moving your website to a different server, or hosting provider. You'd need an easy way to deploy it, and unless it's not under version control, that's a lot of copy/paste that could go wrong. At least it's all in once place if/when something happens.
This isn'y really an answer as much as it's something to consider.
Version them. Why not? I version the PSD's and everything. But if that makes you wince, I can understand. You should version the javascript and stylesheets though, that stuff is code (of sorts).
Now, if by content, you mean "the image I uploaded for a blog post" or "a pdf file I'm using in a comment", then I'd say no--dont version it. That kind of content is accounted for in the database or somewhere else. But the logo image, the sprites, and the stuff that makes up the look and feel of the site should absolutely be versioned.
I'll give you one more touchy-feely reason if you aren't convinced. Some day you'll wish you could go into your history and see what your site looked like 5 years ago. If you versioned your look & feel stuff, you'll be able to do it.
You are completely correct on two points.
You are using Version Control for your code.
You are backing up your live content database.
You have come to the correct conclusion that the "content images" are just that and have no business in your code's Version Control.
Backup your content images along with your database. You do not want to blur the lines between the two unless you want your "code" to be just your own blog site.
What if you wanted to start a completely different blog. Or your friends all wanted one.You wouldn't be giving them a copy of your database with all your content. Nor would it be any use for them to have a copy with all your content images.
Move version control systems don't work well with binary files, that being said, if they're not changing, it makes no (little) difference.
You just have to decide which is easier, backing it up on the repository and the multistep process to add an image/pdf/whatever, or maintaining a separate set of actions for them (including backup). Personally I'd keep them on the version-control. If you're not changing them it's not harming anything. Why worry about something that isn't causing harm?
I think you need to ask yourself why you are using version control and why are you making back-ups Probably because you want to safeguard yourself against loss or damage of your files and in the event of something terrible happens you can fall back on your backups.
If you use version control and a separate backup system you get into the problem of distribution because the latest version of your site lives in different places. What if something does go wrong, then how much effort is it going to take you to restore things? To me, having a distributed system with version control and backup's seems like a lot of manual work that's not easy script-able. Even more, when something does go wrong you're probably already stressed out anyway. Making the restoration process harder will probably not help you much.
The way I see it, putting your static files in version control doesn't do any harm. You have to put them some where anyway be in a version control repository or a normal file system. since your static files never change they're not taking up more space over time, so what's the problem? I recommend you just place all of it under version control and make it easy on yourself. Personally I would make a backup of my database with regular intervals and commit this backup to version control as well. This way you have everything in one place and in the case of disaster you can easily do a new checkout/export to restore your site.
I've build this website. It has over a gig of PDF files and everything is stored under version control. If the server dies, all I have to do is a clean export and re-import the database and the site it up and running again.
If you are working on a web project, I would recommend creating a virtual directory for your media. For example, we setup a virtual directory in our local working copy IIS for /images/ /assets/ etc. which points to the development/staging server that the customer has access to.
This increases the speed of the source control (especially using something clunky like Visual Source Safe), and if the customer changes something during testing, this is automatically reflected in our local working copy.