2009/7/29 Santi Béjar <santi@xxxxxxxxxxx>: > 2009/7/29 demerphq <demerphq@xxxxxxxxx>: >> I was wondering if anybody had any suggestions on a sane way to add a >> file to a git-archive when it is being produced. >> >> For instance build procedures that expect to be run inside of a git >> WD wont work if built from an archived version of the tree. Being able >> to provide a file of additional data to the archive package would be a >> very convenient way to work around this. >> >> Ideally id like to be able to specify a set of additional files to >> include in the archive as part of the git-archive command line >> interface, but I'd be nearly as a happy with almost any solution other >> than the one I came up with, which is to use archive to generate a tar >> file, then use tar to append the additional files to the tar, and then >> compress it. This process turns out to be quite slow in comparison to >> producing a compressed archive directly from git-archive. > > Then I don't know. It is exactly the way it is done in git.git itself, > look the dist target in the makefile. So then git also would benefit from support in git-archive for adding arbitrary files to the archive during generation? One problem here is that we (the Perl project) are supporting VMS smoke-testers and need the ability to provide snapshots that are buildable without using git at all. So we hacked the snapshot support in gitweb to do this. However we dont want to do this for every commit, just the ones that people actually fetch. So while the process we use is fine for rolling a dist, its not so fine when people are expecting a download to start promptly after clicking on the snapshot link. > >> >> Another question is whether anyone has any advice on the best way to >> find out the "best" branch an arbitrary commit is on. Where best can >> be flexibly definied to handle commits that are reachable from >> multiple branches. I have hacked a solution involving git-log and >> grep, but it performs quite poorly. I was wondering if there is a >> better solution. > > The "best" tag is easy: git describe commit. For branches I think you > could use "git name-ref --refs=refs/heads/* commit", because git > describe does not have a --branches flag. Dang, I guess this is from a newer release than mine. So now i have an excuse to upgrade. :-) Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html