Two gitweb feature requests

Two gitweb feature requests

[David Woodhouse]

First... When publishing trees, I currently give both the git:// URL for
people who want to pull the tree, and the http:// URL to gitweb for
those who just want to browse.

It would be useful if I could get away with giving just one URL --
probably the http:// one to gitweb. If gitweb were to have a mode in
which it gave a referral to the git:// URL, and if the git tools would
use that, then that would work well.

Secondly, it would be useful if gitweb would list the branches in a
repository and allow each of them to be viewed in the same way as it
does the master branch.

-- 
dwmw2

Re: Two gitweb feature requests

[Matthias Lederhofer]

> First... When publishing trees, I currently give both the git:// URL for
> people who want to pull the tree, and the http:// URL to gitweb for
> those who just want to browse.
> 
> It would be useful if I could get away with giving just one URL --
> probably the http:// one to gitweb. If gitweb were to have a mode in
> which it gave a referral to the git:// URL, and if the git tools would
> use that, then that would work well.

An easy way to do this is to put the git repository on the webserver
and tell the webserver to redirect to gitweb if the directory is
accessed directly, not a file in the git directory.

Re: Two gitweb feature requests

[David Woodhouse]

On Thu, 2006-04-27 at 15:35 +0200, Matthias Lederhofer wrote:
> An easy way to do this is to put the git repository on the webserver
> and tell the webserver to redirect to gitweb if the directory is
> accessed directly, not a file in the git directory.

That's true, but isn't it much to use git:// instead of the 'dumb'
http:// method?

-- 
dwmw2

Re: Two gitweb feature requests

[Ben Clifford]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 596 bytes --]

On Thu, 27 Apr 2006, David Woodhouse wrote:

> It would be useful if I could get away with giving just one URL --
> probably the http:// one to gitweb. If gitweb were to have a mode in
> which it gave a referral to the git:// URL, and if the git tools would
> use that, then that would work well.

HTML has a <link> element which can be used to indicate alternate forms of 
a page. Gitweb already generates one already to point people at the RSS 
feeds.

Kinda messy to make all the git tools learn how to read HTML, though...

-- 
Ben べン Бэн
http://www.hawaga.org.uk/ben/

Re: Two gitweb feature requests

[David Woodhouse]

On Thu, 2006-04-27 at 22:54 +0000, Ben Clifford wrote:
> HTML has a <link> element which can be used to indicate alternate forms of 
> a page. Gitweb already generates one already to point people at the RSS 
> feeds.
> 
> Kinda messy to make all the git tools learn how to read HTML, though... 

They wouldn't necessarily need to. git-clone and git-pull attempt to use
URLs which wouldn't be used in normal gitweb usage -- for example, any
attempt to fetch http://git.infradead.org/?p=mtd-2.6.git/HEAD or
http://git.infradead.org/?p=mtd-2.6.git/refs/heads can be assumed to be
an attempt to clone or pull with git. So gitweb could be modified to
detect those URLs and give a simple textual redirect which the git tools
could understand.

-- 
dwmw2

Re: Two gitweb feature requests

[sean]

On Thu, 27 Apr 2006 14:27:05 +0100
David Woodhouse <dwmw2@infradead.org> wrote:

> First... When publishing trees, I currently give both the git:// URL for
> people who want to pull the tree, and the http:// URL to gitweb for
> those who just want to browse.
> 
> It would be useful if I could get away with giving just one URL --
> probably the http:// one to gitweb. If gitweb were to have a mode in
> which it gave a referral to the git:// URL, and if the git tools would
> use that, then that would work well.

This sounds like a good idea.

> Secondly, it would be useful if gitweb would list the branches in a
> repository and allow each of them to be viewed in the same way as it
> does the master branch.

At the bottom of the Summary page it already lists the branches,
underneath the tags.

Sean

Re: Two gitweb feature requests

[Jakub Narebski]

I'd like to have 'parent directory' link for trees ('..' link) at the top of
it's contents. I know it is possible to use browser history for that, but
it would give greater similarity with 'directory listing' mode of WWW
servers.

-- 
Jakub Narebski
Warsaw, Poland

Re: Two gitweb feature requests

[Linus Torvalds]

On Fri, 28 Apr 2006, Jakub Narebski wrote:
>
> I'd like to have 'parent directory' link for trees ('..' link) at the top of
> it's contents. I know it is possible to use browser history for that, but
> it would give greater similarity with 'directory listing' mode of WWW
> servers.

Well, a git "tree" doesn't actually _have_ a parent. It potentially has 
multiple.

So to get to "a parent", you literally do need to keep track of how you 
got to the tree. Which is certainly possible (maybe it even ends up being 
in the URI that gitk generates, I didn't check), but basically, if it 
isn't tracked explicitly, it basically is impossible to find.

Not having back-pointers is what allows git to do data sharing and a lot 
of other things efficiently. A tree is a tree is a tree, and has zero data 
about what points to it, so as long as the _contents_ of a tree are the 
same, you have exactly the same object. That means that the same subtree 
can - and will - be pointed to by multiple upper-level trees and commits. 

So you do need that "browser history" one way or another. Either in the 
browser (use the "back button") or by encoding the "how did we get here" 
information in the URI and the dynamically generated page content.

The downside is that you'd have two different web-pages for the same tree 
depending on which commit it came from. Which is not a downside from a 
user perspective, but it's a downside from a caching/server perspective, 
since it means less reuse of pages (maybe gitweb already does that, 
though).

		Linus

Re: Two gitweb feature requests

[Jakub Narebski]

Linus Torvalds wrote:

> On Fri, 28 Apr 2006, Jakub Narebski wrote:
>>
>> I'd like to have 'parent directory' link for trees ('..' link) at the top
>> of it's contents. I know it is possible to use browser history for that,
>> but it would give greater similarity with 'directory listing' mode of WWW
>> servers.
> 
> Well, a git "tree" doesn't actually _have_ a parent. It potentially has
> multiple.

I have forgot about that. Sorry for the noise, then.

[...]

> So you do need that "browser history" one way or another. Either in the
> browser (use the "back button") or by encoding the "how did we get here"
> information in the URI and the dynamically generated page content.

Or use JavaScript via <a href="javascript:history.go(-1)">..</a>
But that wouldn't help me, because when I open the link in new window (new
tab), the new window (new tab) doesn't inherit history from parent... so
browser's "back" button doesn't work. Ah, well...

> The downside is that you'd have two different web-pages for the same tree
> depending on which commit it came from. Which is not a downside from a
> user perspective, but it's a downside from a caching/server perspective,
> since it means less reuse of pages (maybe gitweb already does that,
> though).

Perhaps if "how we get there" information was encoded via POST... but I
don't know if there would be the difference in caching c.f. GET (encoding
in URI).

-- 
Jakub Narebski
Warsaw, Poland

Re: Two gitweb feature requests

[Jeff King]

On Fri, Apr 28, 2006 at 11:23:11AM -0700, Linus Torvalds wrote:

> The downside is that you'd have two different web-pages for the same tree 
> depending on which commit it came from. Which is not a downside from a 
> user perspective, but it's a downside from a caching/server perspective, 
> since it means less reuse of pages (maybe gitweb already does that, 
> though).

The gitweb request for a tree already contains not only the tree hash,
but also the commit hash and the filename path. It's possible (but more
expensive than typical tree requests) to find '..' by munging the path
and traversing the tree from the root.

-Peff

Re: Two gitweb feature requests

[Jakub Narebski]

It would be nice if gitweb provided for the GIT repository description which
doesn't fit the "Description" column and is shortened, and any other text
which doesn't fit it's own column, full text of said field as the "title"
attribute for the cell 'td' element, or encompasing 'span' element. It
would result in having full, not shortened text of said field (e.g.
repository description) in the pop-up on mouse hover over said field. To
simplify things it could be provided unconditionally, regardless whether
the field needs shortening or not.

By the way, would it be possible for the repository without provided
description to stand out more, perhaps by changing formatting of default
description: 
  "Unnamed repository; edit this file to name it for gitweb."
to use ALL CAPS for attention, like that: 
  "UNNAMED REPOSITORY; edit this file to name it for gitweb."
or perhaps if possible use HTML formatting [additionally] for that.

-- 
Jakub Narebski
Warsaw, Poland

Re: Two gitweb feature requests

[Jakub Narebski]

It would be nice if gitweb provided for the GIT repository description 
which doesn't fit the "Description" column and is shortened, and any 
other text which doesn't fit it's own column, full text of said field 
as the "title" attribute for the cell 'td' element, or encompasing 
'span' element. It would result in having full, not shortened text of 
said field (e.g. repository description) in the pop-up on mouse hover 
over said field. To simplify things it could be provided 
unconditionally, regardless whether the field needs shortening or not.

By the way, would it be possible for the repository without provided 
description to stand out more, perhaps by changing formatting of 
default description: 
  "Unnamed repository; edit this file to name it for gitweb."
to use ALL CAPS for attention, like that: 
  "UNNAMED REPOSITORY; edit this file to name it for gitweb."
or perhaps if possible use HTML formatting [additionally] for that.

-- 
Jakub Narebski
Poland