gitweb feature request: tarball for each commit

gitweb feature request: tarball for each commit

[Martin Langhoff]

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

Re: gitweb feature request: tarball for each commit

[Sven Verdoolaege]

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

Re: gitweb feature request: tarball for each commit

[Kay Sievers]

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.

Kay

Re: gitweb feature request: tarball for each commit

[A Large Angry SCM]

Kay Sievers wrote:
> 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.

Re: gitweb feature request: tarball for each commit

[Martin Langhoff]

> > 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