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 git...@googlegroups.com.
To unsubscribe from this group, send email to
github+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/github?hl=en.
