{"thread":{"id":"3975","subject":"Two gitweb feature requests","startedAt":"2006-04-27T13:27:05Z","lastAt":"2006-04-29T21:38:00Z","messageCount":11,"participants":["David Woodhouse","Matthias Lederhofer","Ben Clifford","sean","Jakub Narebski","Linus Torvalds","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"19180","messageId":"1146144425.11909.450.camel@pmac.infradead.org","threadId":"3975","inReplyTo":null,"subject":"Two gitweb feature requests","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-04-27T13:27:05Z","receivedAt":"2006-04-27T13:27:05Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"First... When publishing trees, I currently give both the git:// URL for\npeople who want to pull the tree, and the http:// URL to gitweb for\nthose who just want to browse.\n\nIt would be useful if I could get away with giving just one URL --\nprobably the http:// one to gitweb. If gitweb were to have a mode in\nwhich it gave a referral to the git:// URL, and if the git tools would\nuse that, then that would work well.\n\nSecondly, it would be useful if gitweb would list the branches in a\nrepository and allow each of them to be viewed in the same way as it\ndoes the master branch.\n\n-- \ndwmw2\n"},{"id":"19181","messageId":"E1FZ6eM-0000qC-HH@moooo.ath.cx","threadId":"3975","inReplyTo":"1146144425.11909.450.camel@pmac.infradead.org","subject":"Re: Two gitweb feature requests","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2006-04-27T13:35:18Z","receivedAt":"2006-04-27T13:35:18Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"> First... When publishing trees, I currently give both the git:// URL for\n> people who want to pull the tree, and the http:// URL to gitweb for\n> those who just want to browse.\n> \n> It would be useful if I could get away with giving just one URL --\n> probably the http:// one to gitweb. If gitweb were to have a mode in\n> which it gave a referral to the git:// URL, and if the git tools would\n> use that, then that would work well.\n\nAn easy way to do this is to put the git repository on the webserver\nand tell the webserver to redirect to gitweb if the directory is\naccessed directly, not a file in the git directory.\n"},{"id":"19183","messageId":"1146145626.11909.452.camel@pmac.infradead.org","threadId":"3975","inReplyTo":"E1FZ6eM-0000qC-HH@moooo.ath.cx","subject":"Re: Two gitweb feature requests","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-04-27T13:47:06Z","receivedAt":"2006-04-27T13:47:06Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2006-04-27 at 15:35 +0200, Matthias Lederhofer wrote:\n> An easy way to do this is to put the git repository on the webserver\n> and tell the webserver to redirect to gitweb if the directory is\n> accessed directly, not a file in the git directory.\n\nThat's true, but isn't it much to use git:// instead of the 'dumb'\nhttp:// method?\n\n-- \ndwmw2\n"},{"id":"19201","messageId":"Pine.LNX.4.64.0604272250420.4963@mundungus.clifford.ac","threadId":"3975","inReplyTo":"1146144425.11909.450.camel@pmac.infradead.org","subject":"Re: Two gitweb feature requests","fromName":"Ben Clifford","fromEmail":"benc@hawaga.org.uk","sentAt":"2006-04-27T22:54:46Z","receivedAt":"2006-04-27T22:54:46Z","isPatch":false,"sender":{"key":"benc@hawaga.org.uk","avatar":"https://gravatar.com/avatar/c7ce083471287f8e77b69dd147f757799d1efdd740727fd7e3003f33e88be898?d=mp&s=160"},"body":"On Thu, 27 Apr 2006, David Woodhouse wrote:\n\n> It would be useful if I could get away with giving just one URL --\n> probably the http:// one to gitweb. If gitweb were to have a mode in\n> which it gave a referral to the git:// URL, and if the git tools would\n> use that, then that would work well.\n\nHTML has a <link> element which can be used to indicate alternate forms of \na page. Gitweb already generates one already to point people at the RSS \nfeeds.\n\nKinda messy to make all the git tools learn how to read HTML, though...\n\n-- \nBen べン Бэн\nhttp://www.hawaga.org.uk/ben/\n"},{"id":"19232","messageId":"BAYC1-PASMTP0240D4E75F0F6EE37BA4EBAEB20@CEZ.ICE","threadId":"3975","inReplyTo":"1146144425.11909.450.camel@pmac.infradead.org","subject":"Re: Two gitweb feature requests","fromName":"sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-04-28T16:26:30Z","receivedAt":"2006-04-28T16:26:30Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 27 Apr 2006 14:27:05 +0100\nDavid Woodhouse <dwmw2@infradead.org> wrote:\n\n> First... When publishing trees, I currently give both the git:// URL for\n> people who want to pull the tree, and the http:// URL to gitweb for\n> those who just want to browse.\n> \n> It would be useful if I could get away with giving just one URL --\n> probably the http:// one to gitweb. If gitweb were to have a mode in\n> which it gave a referral to the git:// URL, and if the git tools would\n> use that, then that would work well.\n\nThis sounds like a good idea.\n\n> Secondly, it would be useful if gitweb would list the branches in a\n> repository and allow each of them to be viewed in the same way as it\n> does the master branch.\n\nAt the bottom of the Summary page it already lists the branches,\nunderneath the tags.\n\nSean\n"},{"id":"19233","messageId":"e2tjqm$83n$1@sea.gmane.org","threadId":"3975","inReplyTo":"1146144425.11909.450.camel@pmac.infradead.org","subject":"Re: Two gitweb feature requests","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-28T17:37:03Z","receivedAt":"2006-04-28T17:37:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I'd like to have 'parent directory' link for trees ('..' link) at the top of\nit's contents. I know it is possible to use browser history for that, but\nit would give greater similarity with 'directory listing' mode of WWW\nservers.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19234","messageId":"Pine.LNX.4.64.0604281116020.3701@g5.osdl.org","threadId":"3975","inReplyTo":"e2tjqm$83n$1@sea.gmane.org","subject":"Re: Two gitweb feature requests","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-28T18:23:11Z","receivedAt":"2006-04-28T18:23:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 28 Apr 2006, Jakub Narebski wrote:\n>\n> I'd like to have 'parent directory' link for trees ('..' link) at the top of\n> it's contents. I know it is possible to use browser history for that, but\n> it would give greater similarity with 'directory listing' mode of WWW\n> servers.\n\nWell, a git \"tree\" doesn't actually _have_ a parent. It potentially has \nmultiple.\n\nSo to get to \"a parent\", you literally do need to keep track of how you \ngot to the tree. Which is certainly possible (maybe it even ends up being \nin the URI that gitk generates, I didn't check), but basically, if it \nisn't tracked explicitly, it basically is impossible to find.\n\nNot having back-pointers is what allows git to do data sharing and a lot \nof other things efficiently. A tree is a tree is a tree, and has zero data \nabout what points to it, so as long as the _contents_ of a tree are the \nsame, you have exactly the same object. That means that the same subtree \ncan - and will - be pointed to by multiple upper-level trees and commits. \n\nSo you do need that \"browser history\" one way or another. Either in the \nbrowser (use the \"back button\") or by encoding the \"how did we get here\" \ninformation in the URI and the dynamically generated page content.\n\nThe downside is that you'd have two different web-pages for the same tree \ndepending on which commit it came from. Which is not a downside from a \nuser perspective, but it's a downside from a caching/server perspective, \nsince it means less reuse of pages (maybe gitweb already does that, \nthough).\n\n\t\tLinus\n"},{"id":"19235","messageId":"e2tpbc$ped$1@sea.gmane.org","threadId":"3975","inReplyTo":"Pine.LNX.4.64.0604281116020.3701@g5.osdl.org","subject":"Re: Two gitweb feature requests","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-28T19:11:17Z","receivedAt":"2006-04-28T19:11:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> On Fri, 28 Apr 2006, Jakub Narebski wrote:\n>>\n>> I'd like to have 'parent directory' link for trees ('..' link) at the top\n>> of it's contents. I know it is possible to use browser history for that,\n>> but it would give greater similarity with 'directory listing' mode of WWW\n>> servers.\n> \n> Well, a git \"tree\" doesn't actually _have_ a parent. It potentially has\n> multiple.\n\nI have forgot about that. Sorry for the noise, then.\n\n[...]\n\n> So you do need that \"browser history\" one way or another. Either in the\n> browser (use the \"back button\") or by encoding the \"how did we get here\"\n> information in the URI and the dynamically generated page content.\n\nOr use JavaScript via <a href=\"javascript:history.go(-1)\">..</a>\nBut that wouldn't help me, because when I open the link in new window (new\ntab), the new window (new tab) doesn't inherit history from parent... so\nbrowser's \"back\" button doesn't work. Ah, well...\n\n> The downside is that you'd have two different web-pages for the same tree\n> depending on which commit it came from. Which is not a downside from a\n> user perspective, but it's a downside from a caching/server perspective,\n> since it means less reuse of pages (maybe gitweb already does that,\n> though).\n\nPerhaps if \"how we get there\" information was encoded via POST... but I\ndon't know if there would be the difference in caching c.f. GET (encoding\nin URI).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19242","messageId":"20060429050231.GC25638@coredump.intra.peff.net","threadId":"3975","inReplyTo":"Pine.LNX.4.64.0604281116020.3701@g5.osdl.org","subject":"Re: Two gitweb feature requests","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-04-29T05:02:31Z","receivedAt":"2006-04-29T05:02:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 28, 2006 at 11:23:11AM -0700, Linus Torvalds wrote:\n\n> The downside is that you'd have two different web-pages for the same tree \n> depending on which commit it came from. Which is not a downside from a \n> user perspective, but it's a downside from a caching/server perspective, \n> since it means less reuse of pages (maybe gitweb already does that, \n> though).\n\nThe gitweb request for a tree already contains not only the tree hash,\nbut also the commit hash and the filename path. It's possible (but more\nexpensive than typical tree requests) to find '..' by munging the path\nand traversing the tree from the root.\n\n-Peff\n"},{"id":"19249","messageId":"e2v46t$gu9$1@sea.gmane.org","threadId":"3975","inReplyTo":"1146144425.11909.450.camel@pmac.infradead.org","subject":"Re: Two gitweb feature requests","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-29T11:16:26Z","receivedAt":"2006-04-29T11:16:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"It would be nice if gitweb provided for the GIT repository description which\ndoesn't fit the \"Description\" column and is shortened, and any other text\nwhich doesn't fit it's own column, full text of said field as the \"title\"\nattribute for the cell 'td' element, or encompasing 'span' element. It\nwould result in having full, not shortened text of said field (e.g.\nrepository description) in the pop-up on mouse hover over said field. To\nsimplify things it could be provided unconditionally, regardless whether\nthe field needs shortening or not.\n\nBy the way, would it be possible for the repository without provided\ndescription to stand out more, perhaps by changing formatting of default\ndescription: \n  \"Unnamed repository; edit this file to name it for gitweb.\"\nto use ALL CAPS for attention, like that: \n  \"UNNAMED REPOSITORY; edit this file to name it for gitweb.\"\nor perhaps if possible use HTML formatting [additionally] for that.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"19266","messageId":"1146346681.10561.118.camel@shinybook.infradead.org","threadId":"3975","inReplyTo":"Pine.LNX.4.64.0604272250420.4963@mundungus.clifford.ac","subject":"Re: Two gitweb feature requests","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-04-29T21:38:00Z","receivedAt":"2006-04-29T21:38:00Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2006-04-27 at 22:54 +0000, Ben Clifford wrote:\n> HTML has a <link> element which can be used to indicate alternate forms of \n> a page. Gitweb already generates one already to point people at the RSS \n> feeds.\n> \n> Kinda messy to make all the git tools learn how to read HTML, though... \n\nThey wouldn't necessarily need to. git-clone and git-pull attempt to use\nURLs which wouldn't be used in normal gitweb usage -- for example, any\nattempt to fetch http://git.infradead.org/?p=mtd-2.6.git/HEAD or\nhttp://git.infradead.org/?p=mtd-2.6.git/refs/heads can be assumed to be\nan attempt to clone or pull with git. So gitweb could be modified to\ndetect those URLs and give a simple textual redirect which the git tools\ncould understand.\n\n-- \ndwmw2\n"}]}