For your particular project, it may not cause problems. But throwing around regex's often have unintended consequences.
I'm open to suggestions to make our downloads better, I'm just failing to see a problem that needs fixing. If I download "bup-bup-v2.1-0ccc.tar.gz" I am just as likely to use the software as if I download "bup-v2.1.tar.gz" - Kyle On Mon, Apr 26, 2010 at 11:58 AM, Avery Pennarun <[email protected]> wrote: > Hmm, I think it's neither complex nor tailored only to my needs. Consider: > > - virtually every project wants final release tarballs named > projectname-#.##.##.tar.gz (or #.##-rc#.tar.gz, or whatever); github > tarballs currently do the right thing for precisely zero of the > world's projects, as far as I can see. > > - it's very unlikely that any project uses tags of the form "#.##.##"; > they surely use at least "v#.##.##" instead, so rule #4 is important; > > - a tag of the form "projectname-#.##.##" is pretty common as well > (and probably better than just v#.##.##), and is easy to repair too, > so rule #3 is worthwhile. > > As for rules #1 and #2 conflicting, that's only true if you absolutely > require zero redundancy. My main point is that a project named "bup" > with a tag for version "0.14" has a very low probability of > conflicting with some *other* project named bup, version 0.14. Even > if it did conflict, the probability that the same person needs to > download both tarballs is vanishingly small. And even if they *did* > need to download both tarballs, the recipient is surely aware of the > problem and can just rename one of them. > > As for the complexity argument, programs sound complex when you > describe them in words. The implementation of rules 3 and 4 amounts > to this perl script: > > # $tag is the tagname we're trying to download > # $projname is the project name > $tag =~ s/^$projname-//; > $tag =~ s/^v(\d)/$1/; > > Rule #1 is of the form "just don't insert that in the first place" and > rule #2 is of the form "just use what git describe already does, > rather than overriding it." > > Do you know if there *is* a reason github tarball names are overly > redundant? If so, that would be much more convincing than "it's much > too complex to apply these two regular expressions so that virtually > every project can benefit." > > Thanks, > > Avery > > > On Mon, Apr 26, 2010 at 2:07 PM, Kyle Neath <[email protected]> wrote: > > 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]<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]<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.
