Two gitweb feature requests

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

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.

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

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/

On Thu, 27 Apr 2006 14:27:05 +0100
David Woodhouse [off-list ref] 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

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

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

Linus Torvalds wrote:

On Fri, 28 Apr 2006, Jakub Narebski wrote:

quoted

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

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

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

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