I want allow users to download executable of one of my project on github, without downloading all sources or browsing the entire project.
According to this similar question, you could use a upload/download service, which apparently, github has shut down.
So is there another way? Is github aiming at sharing code only, not software?
Update 2d July 2013, you now can define a release.
Releases are accompanied by release notes and links to download the software or source code.
Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.
You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.
This is what replaces the old binary upload service, which was removed in December 2012!
Ideally, you would store your executable in an artifact repository, as opposed as a source repository like GitHub.
So yes, GitHub is for source control management, not deliveries (like binaries produced from your code).
Nexus is the usual choice for any generated artifacts like binaries, with a free upload possibility for open-source projects.
See "How do I get my software into Central?" (from this answer, also mentioned in "Maven repository hosting for non-public artifacts?")
You can create another repository to host all your builds , I mean executable files . With in that repository don't add any of your code other than your builds ,
As a result of this , people can click on download Zip button at git hub , which downloads only executable ( as a zip file ).
while building you can copy the executable file in a folder just push to remote repository which is hosting only builds .
Hope this helps .
basically , GIT is just an SCM ( source code management system ) it is not meant for this purpose .
but still this how you can utilize the service of github.org amd git .
hope this helps .
EDIT : -
Git hub now has a solution for hosting releases it has been well explained by #VonC in the post below . Please use that as a solution.
The following worked for me, YMMV. On a MAC and using Chrome browser, after getting to this page I clicked on the "Raw" button (the "View Raw" link also worked), and it downloaded the executable tatuMicro.kit to my Downloads folder
An exe file can be hosted under releases and the link can be distributed among friends etc. I tested it as recently as yesterday. Only issue is if someone sabotages the program for profit. The exe files can be moved around and distributed easily on pendrives.
Related
We are trying to set up Eclipse so that two users can share the same project directory on our server. Is this possible? Every time we try, it creates a new folder and project.
Thanks!
Chris
No, this isn't possible. Eclipse only supports a single user accessing a workspace (not just a project) at a time.
Use a source control system such as Git or SVN to share code. Eclipse supports many such systems and has extensive sharing support in the 'Team' menus.
The best way to do this would be to use source control.
Sharing the actual workspace or the files with different eclipse instance is a recipe for trouble.
An easy way to do this would be to install git on your machine and also on his machine. Eclipse actually already has git in it ready to go so you probably dont need to install anything.
The one with the files locally will create a repo locally on his computer and commit the files to it.
Next you want to init a new empty repository on a shared folder and push your local chances to this as you would to github for example.
Your partner can then git clone from this repository to his machine and work locally.
Each of you will develop on your own copy and commit your changes locally. You will share your changes by pushing your commits in that central repo and pulling from it to get changes from your partner.
You could also just open an account on GitHub, GitLab or BitBucket (there are many others too) and use that instead of a shared folder. big advantage with these services is that they will be available from anywhere.
I have heard that cryengine V provides access to the full source code, but I can't find where to download the source code.
Anyone can tell me how to download the source code of cryengine V?
There are two ways to get CryEngine's source code from Github:
Download specific revision. For this, visit CryEngine public repository on Github, find a large green button on the right titled "Clone or download", and in a dropdown menu choose "Download ZIP". It will download a zipped version of the source code for you.
Via Git client. For that, install Git from its official site. If you already have Git installed, use some Git GUI client to clonse the repository, or create a directory, cd to that directory in console/terminal, and run command:
git clone https://github.com/CRYTEK-CRYENGINE/CRYENGINE.git
This way will also allow you to make pull requests to send fixes back to Crytek if you like.
PS. In order to get SDKs which contains much of the Sandbox content as well as samples, you possibly would also like to download GameSDK repository.
PS2. These instructions will let you get the latest version of CryEngine. In order to download specific one, move to releases tab on Github website.
There you go: https://www.cryengine.com/get-cryengine
Just register and you get the engine downloader.
We recently moved from subversion to git, and then to Github, for several open source projects. Github was nice in that it provided a lot of functionality. One of the things I particularly like is the ability to download tags as zip or .tar.gz files.
Unfortunately Github recently discontinued downloads. That shouldn't be a problem because of the ability to download tags. However in the past we have not put a Makefile , configure script or any other autoconf-generated files into the repo because they get lots of conflicts when people merge.
What's the proper way to handle this?
Should I put autoconf and automake-generated files in the repo so people can download tags directly?
Or should there be a bootstrap.sh file and people are told to run that?
Or should I just do a make dist and put that into the repo?
Thanks
Publish the output of make dist via GitHub Releases
Your first option—putting the Autoconf- and Automake-generated files into the repository—is not a good idea. It's almost never beneficial to store generated files in source control. In this case, it's going to pollute your history with a lot of unnecessary and potentially conflicting commits, particularly if not all your contributors are using the same version of Autotools. Your third option—checking in the output of make dist—is a bad idea for exactly the same reasons as the first option.
Your second option—adding a "bootstrap" script that calls Autoconf and Automake to generate the configure scripts—is also a bad idea. This defeats the entire purpose of Autotools, which is to make your source portable across systems—including those for which Autotools is not available! (Consider what would happen if someone wanted to build and install your software on a machine on which they don't have root access, and where the GNU Build System is not installed. A bootstrap script is not going to help them because they'd first need to make a local installation of Autotools and possibly all its dependencies.)
The proper way of releasing code that uses Autotools is to produce a tarball with make dist (or better yet, make distcheck, since this will also run tests and do other sanity checks), and then publish this tarball somewhere other than the source repository.
Your original question, from April 2013, states that GitHub discontinued download pages. However, in July 2013, GitHub added a "Releases" feature that not only pre-packages your source tags, but also allows you to attach arbitrary files to each release. So on GitHub, the Releases page is where you should publish your make dist tarballs (and preferably also the detached GnuPG signatures of them).
Basic steps
When you are ready to make a release, tag it and push the tag to GitHub:
$ git tag 1.0 # Also use -s if desired
$ git push --tags
Use your Makefile to produce a tarball:
$ make dist # Alternatively, 'make distcheck'
Visit the GitHub page for your project and follow the "releases" link:
You will be taken to the Releases page for your project. The first time you visit, all you will see is a list of tags and automatically produced tarballs from the source tree:
Press the "Draft a new release" button.
You will then be presented with a form in which you should fill in the Git tag associated with the release and an optional title and description. Below this there is also a file selector labelled "Attach binaries by dropping them here or selecting them". Use this to upload the tarball you created in Step 2 (and maybe also a detached GnuPG signature of it).
When you're done, press the "Publish release" button.
Your project's Releases page will now display the release, including prominent download links for the attached files:
If you don't want to use GitHub Releases, then as pointed out in a previous answer, you should upload the tarballs somewhere else, such as your own website or FTP site. Add a link to this repository from your project's README.md so that users can find it.
The second is better: you want any user of your repo to be up and running as fast as possible, re-generating what he/she needs in order to build your program.
Since Git is very much a version control for text (as opposed to an artifact repo like Nexus), providing a way to generate the final binary is the way to go.
When you cut a release, upload the result of make distcheck to your project's download page: it's a makefile target that builds the tarball and verifies that it installs, uninstalls, passes tests and other sanity checks. Github being wrong-headed isn't an excuse: create a tree like this in your repo:
/
/source
/source/configure.ac
/source/Makefile.am
/source/...
/releases
/releases/foo-0.1.tar.gz
/releases/...
For developers, you should not have generated files in source control. Many modern autotooled projects bootstrap fine off an invocation of autoreconf -i.
I have a small github repo to convert MS Word Documents, but most people will just want the binary.
Should I
Reorganise my repo to have a src/ and bin/ directories with the most up to
date .exe in with the code and expect people to download the whole lot?
Compile and place my binary somewhere else on the web and link to it?
Include my binary in my repo but link to it seperately?
To host that binary for your application, you now can, since 2nd July 2013, define a release.
Releases, a workflow for shipping software to end users.
Releases are first-class objects with changelogs and binary assets that present a full project history beyond Git artifacts. They're accessible from a repository's homepage:
Releases are accompanied by release notes and links to download the software or source code.
Following the conventions of many Git projects, releases are tied to Git tags. You can use an existing tag, or let releases create the tag when it's published.
You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.
That replaces the old binary upload service, which was removed in December 2012 (as you mention in your question).
Probably not what you want to hear, but in your case this is mostly personal preference.
You don't have to store the binary in the repo, because it is no important dependency.
It is the other way around: everything you need to recreate the file should be in your repository (including Makefiles/project files).
You can store the binary in the repo because it is fairly small.
You should not store it in the repository when the overall size in the repository (base size + diffs, depending how big the diffs are) is overwhelming, but this does not seem to be the case (500 KiB according to your repo).
My personal preference is to never store generated files (binaries, but also generated text files) in the repo.
Possibly because I have experience with 2 GiB csv repositories that take ages to pull. (to be fair: it also takes ages to compile)
For my github project I created a subdomain on some webspace where I put all my downloads and the index page of that subdomain forwards to my github-pages.
The github pages link to the downloads on my webspace subdomain.
Just because I like my github subdomain a bit more for this project.
My tool works for different platforms though, so not every user needs every binary file.
The binaries actually are backends (therefore dependencies), but interchangeable/optional
You can have a look at my setup.
You can try this:
http://sourceforge.net/publish/?source=github
It looks promising to be able to "create on Github but distribute on Sourceforge".
I am working inside a private repository, and collaborate with my friend, who are not very friendly with SCM and stuff. All he need is to monitor the latest release from my development, which is 1 single executable file.
I was wondering instead of cloning the whole repo each time he want to get the latest changes (sometimes my changeset can consists of several large binary files that only being used upon development, not testing). Can I bind the executable file into the Download section in BitBucket?. So that everytime I build my project, the executable file will appear in the Download section and he can download it right away.
For now all I can see from Bitbucket's download section is just the manual upload and Tag/Snapshot download, which I presume will pack a certain changesets into a compressed file. Is there any chance I can do this?.
Thanks.
If your executable file is checked into the repository, you can link to it at a specific revision:
https://staging.bitbucket.org/<username>/<repo>/raw/<revision>/file.exe
For example, this link will always give you the latest stable hg(1) man page from the Mercurial repository:
https://bitbucket.org/mirror/mercurial/raw/stable/doc/hg.1.txt
This would give you latest README on the default branch from the Django repository:
https://bitbucket.org/django/django/raw/default/README
If your executable isn't checked into the repository (some prefer not to check in build artifacts), you'll need to manually upload them in the downloads section of your repository. There isn't a REST API for creating project downloads at the moment.
Would giving your friend an archive of the tip work? Try this URL:
https://bitbucket.org/<username>/<project>/get/tip.tar.gz
#Idan's suggestion might already work for you, but if the archive is too big, you could set up an extra repository for binaries which automatically gets updated, committed and pushed by your build process. Then your fellow developer could download a comparatively small tip archive as suggested by Idan.
In addition to Idan's answer:
To fetch the latest version from the 'default' branch:
https://bitbucket.org/<username>/<project>/get/default.tar.gz
You can replace 'default' by any other branch name, tag name or changeset (if you know it).