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.

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:

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

On Thu, 27 Apr 2006, David Woodhouse 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...

On Thu, 2006-04-27 at 22:54 +0000, Ben Clifford wrote:

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.

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

This sounds like a good idea.

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.

On Fri, 28 Apr 2006, Jakub Narebski wrote:

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:

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

[...]

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

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

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

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.