This sounds extremely complex, and very tailored for your specific needs rather than the whole of the GitHub community (especially #3 & #4). Also, so long as I'm reading it correctly, your reasoning in #1 relies on #2 not being implemented.
What's stopping you from having traditional tarball releases right now? - Kyle On Sun, Apr 25, 2010 at 11:24 AM, Avery Pennarun <[email protected]> wrote: > Hi all, > > Thanks for making github. It's awesome. > > I'm now about 99% of the way to being able to make "traditional-style" > tarball releases by creating just a single git tag, based on the only > mild insanity in this commit: > > > http://github.com/apenwarr/bup/commit/7949755a2e9fc27ddcc9239efa6cd4c0f47f4d11 > > Basically, it uses the .gitattributes "export-subst" feature to make > 'git archive' (and thus github) insert the tag name of the current > commit into the resulting tarball, so that we can then use it as the > version number. > > All that remains is to make the tarball's filename come out correctly. > Sadly, when I download something like this: > > http://github.com/apenwarr/bup/tarball/bup-0.14 > > I get a file called "apenwarr-bup-bup-0.14-0-g0e3565a.tar.gz". So close! > > Based on a previous thread on this list, I tried the advice from here: > > http://blog.usarundbrief.com/?p=36 > > Which advises using an URL like this: > > http://github.com/apenwarr/bup/tarball/bup-0.14/bup-0.14.tar.gz > > However, it seems that because of the way github does HTTP redirects, > this doesn't actually change name that gets downloaded. Maybe this > used to work but stopped working at some point, or maybe the "Pause" > thing he's talking about doesn't notice renames across redirects > (which I guess is just a convenient bug on their part). > > Regardless, even if that feature *had* worked, it's not entirely > useful because all the download links built into github refer to the > default name, not that nice name. > > So my suggestion is to make the github download links use a nice name > automatically. In this case, I'd suggest the following rules: > > 1. Don't include the username (apenwarr-) in the filename. It adds > nothing and is redundant with the rest of the name, especially the tag > name and commit id. (It's totally irrelevant if I download > apenwarr-bup-g0e3565a.tar.gz or jsmith-bup-g0e3565a.tar.gz, since any > tarball based on that commitid is guaranteed to be identical.) > > 2. Don't include the commit id if a tag matches exactly, ie. if > there's a "-0-" field. (Skipping the commit id in that case is the > default behaviour of 'git describe' anyway, so you must have changed > it for a reason. What's the reason?) Thus, "-0-g0e3565a" is > redundant and can be left out. Obviously if it *doesn't* match a tag > exactly, adding the commitid is awesome, as in -1-g7a224c0 or > whatever. We would want to keep that. > > 3. If the tag starts with "{projectname}-", remove that. I have tags > named bup-#.## for my bup project, which is why we get files named > *-bup-bup-0.14-*, for example. The second bup is redundant in the > filename. (I know a lot of projects use things like 'v#.##', but I > avoid this because it causes tag pollution when you use tools like > git-subtree or otherwise fetch one repo into another. Some other > projects are similarly careful.) > > 4. (Applied to a tag name after applying rule #3:) If the tag starts > with v followed by a digit, remove the leading v. (For example: > http://github.com/git/git/tarball/v1.7.1-rc2 should produce > git-1.7.1-rc2.tar.gz) > > By following these rules, github would have produced the filename > "bup-0.14.tar.gz" automatically for my bup-0.14 tag in apenwarr/bup, > which would have been wonderful. > > Now, I read somewhere else in the list archives that some of this > stuff might be related to downloading directly from Amazon S3. If so, > the extra-specific filenames might be used to avoid possible rare > cases of filename overlap. For example, if apenwarr/bup and > jsmith/bup both have a bup-0.14 tag and they're *different*, or if I > have a v0.14 and a bup-0.14 tag, or if (very unlikely) there are two > commit ids in the same project that start with 0e3565a. > > This is a valid concern if you store all your tarballs in a flat > namespace. However, you should be able to resolve it by putting the > uniquifiers in the full path but not the base filename, like this: > > /.../apenwarr/0e3565afb1cc11683eae5107d80d7d7ef66ed34c/bup-0.14.tar.gz > > Then even if there's more than one file in all of github whose name > reduces to bup-0.14.tar.gz, you can store them all safely. > > Please let me know if I've missed anything. We're only one step away > from having fully automated tarball releases (for the people who still > rely on tarballs), and this seems to me, perhaps naively, that it'd be > a pretty simple change. > > Have fun, > > Avery > > -- > You received this message because you are subscribed to the Google Groups > "GitHub" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<github%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/github?hl=en. > > -- You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/github?hl=en.
