# Two gitweb feature requests 11 messages from 2006-04-27 to 2006-04-29. Participants: David Woodhouse, Matthias Lederhofer, Ben Clifford, sean, Jakub Narebski, Linus Torvalds, Jeff King. Thread: https://gitlist.dev/t/3975 ## David Woodhouse, 2006-04-27 13:27 Subject: Two gitweb feature requests Message-ID: <1146144425.11909.450.camel@pmac.infradead.org> URL: https://gitlist.dev/e/1146144425.11909.450.camel%40pmac.infradead.org ``` 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 ``` ## Matthias Lederhofer, 2006-04-27 13:35 Subject: Re: Two gitweb feature requests Message-ID: URL: https://gitlist.dev/e/E1FZ6eM-0000qC-HH%40moooo.ath.cx In-Reply-To: <1146144425.11909.450.camel@pmac.infradead.org> ``` > 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. ``` ## David Woodhouse, 2006-04-27 13:47 Subject: Re: Two gitweb feature requests Message-ID: <1146145626.11909.452.camel@pmac.infradead.org> URL: https://gitlist.dev/e/1146145626.11909.452.camel%40pmac.infradead.org In-Reply-To: ``` 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 ``` ## Ben Clifford, 2006-04-27 22:54 Subject: Re: Two gitweb feature requests Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0604272250420.4963%40mundungus.clifford.ac In-Reply-To: <1146144425.11909.450.camel@pmac.infradead.org> ``` 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 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/ ``` ## sean, 2006-04-28 16:26 Subject: Re: Two gitweb feature requests Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP0240D4E75F0F6EE37BA4EBAEB20%40CEZ.ICE In-Reply-To: <1146144425.11909.450.camel@pmac.infradead.org> ``` On Thu, 27 Apr 2006 14:27:05 +0100 David Woodhouse 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 ``` ## Jakub Narebski, 2006-04-28 17:37 Subject: Re: Two gitweb feature requests Message-ID: URL: https://gitlist.dev/e/e2tjqm%2483n%241%40sea.gmane.org In-Reply-To: <1146144425.11909.450.camel@pmac.infradead.org> ``` 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 ``` ## Linus Torvalds, 2006-04-28 18:23 Subject: Re: Two gitweb feature requests Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0604281116020.3701%40g5.osdl.org In-Reply-To: ``` 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 ``` ## Jakub Narebski, 2006-04-28 19:11 Subject: Re: Two gitweb feature requests Message-ID: URL: https://gitlist.dev/e/e2tpbc%24ped%241%40sea.gmane.org In-Reply-To: ``` 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 .. 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 ``` ## Jeff King, 2006-04-29 05:02 Subject: Re: Two gitweb feature requests Message-ID: <20060429050231.GC25638@coredump.intra.peff.net> URL: https://gitlist.dev/e/20060429050231.GC25638%40coredump.intra.peff.net In-Reply-To: ``` 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 ``` ## Jakub Narebski, 2006-04-29 11:16 Subject: Re: Two gitweb feature requests Message-ID: URL: https://gitlist.dev/e/e2v46t%24gu9%241%40sea.gmane.org In-Reply-To: <1146144425.11909.450.camel@pmac.infradead.org> ``` 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 ``` ## David Woodhouse, 2006-04-29 21:38 Subject: Re: Two gitweb feature requests Message-ID: <1146346681.10561.118.camel@shinybook.infradead.org> URL: https://gitlist.dev/e/1146346681.10561.118.camel%40shinybook.infradead.org In-Reply-To: ``` On Thu, 2006-04-27 at 22:54 +0000, Ben Clifford wrote: > HTML has a 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 ```