threads / discuss / 1751

gitweb feature request: tarball for each commit

Subject: gitweb feature request: tarball for each commit

## tl;dr

5 messages between Sep 8, 2005 and Sep 8, 2005.

replies: 4people: 4as markdown or json

Martin Langhoff· Sep 8, 2005, 04:30 UTC · lore

With Archzoom, when looking at a particular commit/cset you get a small "[tarball]" link that does an 'export' of the whole tree at that patchlevel and tars it up for the user. It's heavy on the server and bandwidth, but if you can afford it, it is mighty useful to push out patches immediately to non-git-using end users.

Here's an example of an archzoom page --- it's among the top-right links. I'm sure we could do something like this with git-tar-tree...

Actually... should get it done. I'll see if I can sneak it in sometime soon...

cheers,

martin

Sven Verdoolaege· Sep 8, 2005, 08:45 UTC · re: Martin Langhoff · lore

Re: gitweb feature request: tarball for each commit

On Thu, Sep 08, 2005 at 04:30:22PM +1200, Martin Langhoff wrote:

> Actually... should get it done. I'll see if I can sneak it in sometime soon...

This has been done at least twice already. See e.g., http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary Check the archives for the other implementation.

skimo

Kay Sievers· Sep 8, 2005, 11:32 UTC · re: Sven Verdoolaege · lore

Re: gitweb feature request: tarball for each commit

On Thu, Sep 08, 2005 at 10:45:45AM +0200, Sven Verdoolaege wrote:

Show 6 quoted lines

> On Thu, Sep 08, 2005 at 04:30:22PM +1200, Martin Langhoff wrote:
> > Actually... should get it done. I'll see if I can sneak it in sometime soon... 
> 
> This has been done at least twice already.
> See e.g., http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
> Check the archives for the other implementation.

Yes, this is nice for smaller projects. But I don't think, that we want to do such a thing on the kernel.org servers. We already have the daily snapshots and individual patches can be downloaded from gitweb. Anybody else should use git/cogito instead of letting the server packaging a huge tree for every requested revison, I think.

Kay

A Large Angry SCM· Sep 8, 2005, 14:03 UTC · re: Kay Sievers · lore

Re: gitweb feature request: tarball for each commit

Kay Sievers wrote:

Show 12 quoted lines

> On Thu, Sep 08, 2005 at 10:45:45AM +0200, Sven Verdoolaege wrote:
>>On Thu, Sep 08, 2005 at 04:30:22PM +1200, Martin Langhoff wrote:
>>>Actually... should get it done. I'll see if I can sneak it in sometime soon... 
>>This has been done at least twice already.
>>See e.g., http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
>>Check the archives for the other implementation.
> 
> Yes, this is nice for smaller projects. But I don't think, that we want
> to do such a thing on the kernel.org servers. We already have the daily
> snapshots and individual patches can be downloaded from gitweb. Anybody
> else should use git/cogito instead of letting the server packaging a huge
> tree for every requested revison, I think.

I think this is a very useful feature for for some, but not all, repositories. Default it to off and have a magic file (like git-daemon), or a config variable turn it on.

Martin Langhoff· Sep 8, 2005, 22:23 UTC · re: A Large Angry SCM · lore

Re: gitweb feature request: tarball for each commit

Show 6 quoted lines

> > Yes, this is nice for smaller projects. But I don't think, that we want
> > to do such a thing on the kernel.org servers. 
>
> I think this is a very useful feature for for some, but not all,
> repositories. Default it to off and have a magic file (like git-daemon),
> or a config variable turn it on.

+1! It'd be murder for large and/or popular projects, but it's a really conventient thing to have as an optional feature. Archzoom has it, and defaults to off ;)

I've checked out Sven's tree as well -- his implementation is pretty cool actually, much more sophisticated that I'd planned, and using POST to avoid stupid bots requesting the tarballs.

In this situation ("look at my repo via gitweb, it has some cool patches over otherhacker's branch") it is hard to discriminate what patches differentiate Sven's repo from Kay's. I'm thinking of, when looking at a branch, having a link that shows the equivalent of `cg-log -r thisbranch:origin` and another one for `cg-log -r origin:thisbranch`.

cheers,

martin