{"thread":{"id":"29568","subject":"Git documentation at kernel.org","startedAt":"2012-02-07T12:28:14Z","lastAt":"2012-02-14T22:15:25Z","messageCount":21,"participants":["Petr Onderka","Clemens Buchacher","Junio C Hamano","Neal Kreitzinger","Matthieu Moy","Theodore Tso","Konstantin Ryabitsev","Ted Ts'o","Jeff King","Scott Chacon"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"184118","messageId":"CAPyqok3USqMxm0gNf_T9vnCoicp9XSwpWUCYJ8jh79h=V_UuOA@mail.gmail.com","threadId":"29568","inReplyTo":null,"subject":"Git documentation at kernel.org","fromName":"Petr Onderka","fromEmail":"gsvick@gmail.com","sentAt":"2012-02-07T12:28:14Z","receivedAt":"2012-02-07T12:28:14Z","isPatch":false,"sender":{"key":"gsvick@gmail.com","avatar":"https://avatars.githubusercontent.com/u/287848?v=4"},"body":"Hi,\n\nsince the hacking of kernel.org, the online version of git\ndocumentation [1] is not available. I realize that I can use local\nversion of the documentation and there is also at least one mirror\n[2]. But I think it's very useful to have an \"official\" version of the\ndocumentation online. And, more importantly, there is now lots of dead\nlinks all over the Internet to the kernel.org version of the\ndocumentation.\n\nCan someone with the ability to do so restore the documentation at the\nold location?\n\nThanks.\n\nPetr Onderka\n\n[1]: http://www.kernel.org/pub/software/scm/git/docs/git.html\n[2]: http://schacon.github.com/git/git.html\n"},{"id":"184203","messageId":"20120208213410.GA5768@ecki","threadId":"29568","inReplyTo":"CAPyqok3USqMxm0gNf_T9vnCoicp9XSwpWUCYJ8jh79h=V_UuOA@mail.gmail.com","subject":"Re: Git documentation at kernel.org","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-02-08T21:34:10Z","receivedAt":"2012-02-08T21:34:10Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"Hi,\n\nPlease restore access to the following files when possible. Some sites\nare referencing those, including kernel.org itself:\n\n http://www.kernel.org/pub/software/scm/git/docs/git.html\n and references therein\n\n http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html\n referenced by\n https://git.wiki.kernel.org/articles/g/i/t/GitFaq_ebc3.html#How_do_I_clone_a_subdirectory.3F\n\nAlso, it would be great if the git wiki could be made editable again.\n\nThank you for your consideration.\n\nRegards,\nClemens\n"},{"id":"184292","messageId":"7vmx8rtu3e.fsf@alter.siamese.dyndns.org","threadId":"29568","inReplyTo":"20120208213410.GA5768@ecki","subject":"Re: Git documentation at kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-10T00:23:01Z","receivedAt":"2012-02-10T00:23:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Clemens Buchacher writes:\n\n> Please restore access to the following files when possible. Some sites\n> are referencing those, including kernel.org itself:\n>\n> http://www.kernel.org/pub/software/scm/git/docs/git.html\n\nThe pages reachable from this used to be living documents in that every\ntime the 'master' branch was updated at k.org, automatically a server side\nhook script generated a new set of HTML pages and updated them.\n\nMy understanding is that we do not want to run such random server side\nhooks at k.org, so it no longer can be a living document anymore.\n\nIt might be a workable short term workaround to redirect\n\n http://www.kernel.org/pub/software/scm/git/docs/$anything\n\nto\n\n http://schacon.github.com/git/$anything\n\nalthough that would not give you an access to the list of documentations\nfor older releases, e.g.\n\n http://www.kernel.org/pub/software/scm/git/docs/v1.6.0/git.html\n\n> Also, it would be great if the git wiki could be made editable again.\n\nAmen.\n"},{"id":"184304","messageId":"4F346D02.2020603@gmail.com","threadId":"29568","inReplyTo":"CAPyqok3USqMxm0gNf_T9vnCoicp9XSwpWUCYJ8jh79h=V_UuOA@mail.gmail.com","subject":"Re: Git documentation at kernel.org","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-02-10T01:04:02Z","receivedAt":"2012-02-10T01:04:02Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 2/7/2012 6:28 AM, Petr Onderka wrote:\n\n> since the hacking of kernel.org, the online version of git\n> documentation [1] is not available. I realize that I can use local\n> version of the documentation and there is also at least one mirror\n> [2]. But I think it's very useful to have an \"official\" version of the\n> documentation online. And, more importantly, there is now lots of dead\n> links all over the Internet to the kernel.org version of the\n> documentation.\n>\n> Can someone with the ability to do so restore the documentation at the\n> old location?\n>\nAdditional info: \nhttp://article.gmane.org/gmane.comp.version-control.git/185302\n\nv/r,\nneal\n"},{"id":"184365","messageId":"vpqbop6tyj6.fsf@bauges.imag.fr","threadId":"29568","inReplyTo":"7vmx8rtu3e.fsf@alter.siamese.dyndns.org","subject":"Re: Git documentation at kernel.org","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-02-10T16:59:25Z","receivedAt":"2012-02-10T16:59:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Clemens Buchacher writes:\n>\n>> Please restore access to the following files when possible. Some sites\n>> are referencing those, including kernel.org itself:\n>>\n>> http://www.kernel.org/pub/software/scm/git/docs/git.html\n>\n> The pages reachable from this used to be living documents in that every\n> time the 'master' branch was updated at k.org, automatically a server side\n> hook script generated a new set of HTML pages and updated them.\n\nIs it possible to have the static HTML uploaded from another machine,\nnot necessarily for each push, but e.g. for every release?\n\nI don't think anyone cares about having the very latest documentation\nthere, but it would still be great to have an official place to point to\nwhen writing documentation on the web about such or such command.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"184372","messageId":"FC56A942-EE70-48B7-A2D3-CF53A189A55E@mit.edu","threadId":"29568","inReplyTo":"vpqbop6tyj6.fsf@bauges.imag.fr","subject":"Re: Git documentation at kernel.org","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2012-02-10T18:00:34Z","receivedAt":"2012-02-10T18:00:34Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"\nOn Feb 10, 2012, at 11:59 AM, Matthieu Moy wrote:\n> \n> Is it possible to have the static HTML uploaded from another machine,\n> not necessarily for each push, but e.g. for every release?\n> \n> I don't think anyone cares about having the very latest documentation\n> there, but it would still be great to have an official place to point to\n> when writing documentation on the web about such or such command.\n\nI think that's a great idea.\n\nI used to use that service quite a lot, so I'd be willing to push the tar balls\nto kernel.org, since I have PGP key set up for kernel.org uploads (so do\nother people, and if someone else wants to do it, I'm happy to let them get\nall the glory :-) Most of the infrastructure to do this has been implemented,\nexcept for the part where the tar ball gets unpacked in the correct directory.\n\nThis would satisfy the security concerns, and it wouldn't be hard, but it would\nrequire some implementation work. Anyone have some perl hacking time to\ntake a look at: \n\n git://git.kernel.org/pub/scm/utils/kup/kup.git\n\n… and add a \"UNPACK pathanme\" to the kup-server file, and work with the\nsysadmins at kernel.org to get it reviewed and accepted?\n\n-- Ted\n"},{"id":"184377","messageId":"1328900154.3171.27.camel@i5.mricon.com","threadId":"29568","inReplyTo":"FC56A942-EE70-48B7-A2D3-CF53A189A55E@mit.edu","subject":"Re: Git documentation at kernel.org","fromName":"Konstantin Ryabitsev","fromEmail":"icon@mricon.com","sentAt":"2012-02-10T18:55:54Z","receivedAt":"2012-02-10T18:55:54Z","isPatch":false,"sender":{"key":"icon@mricon.com","avatar":null},"body":"On Fri, 2012-02-10 at 13:00 -0500, Theodore Tso wrote:\n> This would satisfy the security concerns, and it wouldn't be hard, but it would\n> require some implementation work. Anyone have some perl hacking time to\n> take a look at: \n> \n> git://git.kernel.org/pub/scm/utils/kup/kup.git\n> \n> … and add a \"UNPACK pathanme\" to the kup-server file, and work with the\n> sysadmins at kernel.org to get it reviewed and accepted?\n\nI have a few comments off the top of my head:\n\n 1. \"kup rm\" will need to be modified, as it currently only allows\n deleting things that have a matching signature. The alternative\n is for UNPACK to create a foo.tar.manifest file that will be\n consulted upon \"kup rm\" to clean up any unpacked contents upon\n the deletion of the source archive. Note, that there are many,\n many gotchas with this solution -- e.g. .manifest should\n probably contain checksums, too, as there are bound to be\n conditions when two tarballs reference the same files, and you\n want to make sure that you delete files matching the contents of\n the old tarball, not the newer one, etc.\n 2. I would suggest that UNPACK ignores any directory structure in\n the archive, and only copies over files matching a restricted\n set of extensions (.html, .txt, .jpg, .png) into the same dir as\n the original tarball. Basically, untar into a temporary\n directory, then find any files matching the above set of\n extensions, copy them into another temporary location, force\n permissions to 0644, and then move them into the final \"live\"\n location in the same dir with the tarball (with the\n corresponding .manifest, if that solution used). There should be\n logic to make sure that we never overwrite any files that have a\n matching .sign file.\n 3. There should be some support to ensure that the unpack process\n is terminated if unpacked content size reaches a certain limit,\n or if it is taking too long to complete.\n\nBest regards,\n-- \nKonstantin Ryabitsev\nSystems Administrator, Kernel.org\nMontréal, Québec\n"},{"id":"184383","messageId":"7vobt6piud.fsf@alter.siamese.dyndns.org","threadId":"29568","inReplyTo":"vpqbop6tyj6.fsf@bauges.imag.fr","subject":"Re: Git documentation at kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-10T19:51:54Z","receivedAt":"2012-02-10T19:51:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>\n>> Clemens Buchacher writes:\n>>\n>>> Please restore access to the following files when possible. Some sites\n>>> are referencing those, including kernel.org itself:\n>>>\n>>> http://www.kernel.org/pub/software/scm/git/docs/git.html\n>>\n>> The pages reachable from this used to be living documents in that every\n>> time the 'master' branch was updated at k.org, automatically a server side\n>> hook script generated a new set of HTML pages and updated them.\n>\n> Is it possible to have the static HTML uploaded from another machine,\n> not necessarily for each push, but e.g. for every release?\n\nIt would probably be possible, but I do not have that much time and\npatience to sign 600+ files in the preformatted HTML tree one-by-one and\nupload them using kup.\n"},{"id":"184385","messageId":"20120210195736.GA5381@thunk.org","threadId":"29568","inReplyTo":"1328900154.3171.27.camel@i5.mricon.com","subject":"Re: Git documentation at kernel.org","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2012-02-10T19:57:36Z","receivedAt":"2012-02-10T19:57:36Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"How about this as something *way* simpler? Define a way of marking\nthe top of a particular directory hierarchy as a tree. Then the\n*only* way of updating that tree is all or nothing. That is, someone\nsubmits a signed tarball; then after the signed tarball has its\nsignature checked, it gets unpacked into a dir.new, and then we rename\ndir to dir.old, rename dir.new to dir, and then dir.old gets removed.\n\nThat way there's no conflicts between directories that are managed via\nthe kup-servers PUT and DELETE commands, and those where they get\nuploaded as a single tarball to create or replace a specific directory\nhierarcy, or which can be deleted only as a entire directory hierarcy.\n\nWhat do you think?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"184386","messageId":"20120210200100.GA5504@sigill.intra.peff.net","threadId":"29568","inReplyTo":"1328900154.3171.27.camel@i5.mricon.com","subject":"Re: Git documentation at kernel.org","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-10T20:01:00Z","receivedAt":"2012-02-10T20:01:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 10, 2012 at 01:55:54PM -0500, Konstantin Ryabitsev wrote:\n\n> I have a few comments off the top of my head:\n> \n> 1. \"kup rm\" will need to be modified, as it currently only allows\n> deleting things that have a matching signature. The alternative\n> is for UNPACK to create a foo.tar.manifest file that will be\n> consulted upon \"kup rm\" to clean up any unpacked contents upon\n> the deletion of the source archive. Note, that there are many,\n> many gotchas with this solution -- e.g. .manifest should\n> probably contain checksums, too, as there are bound to be\n> conditions when two tarballs reference the same files, and you\n> want to make sure that you delete files matching the contents of\n> the old tarball, not the newer one, etc.\n\nFor this particular use case, I don't know if that would be necessary.\nAccording to Junio, previously:\n\n The k.org site kept these files under /pub/software/scm/git/docs/. The\n in-development \"master\" version of pages were placed directly\n underneath that directory, and the documentation pages for older\n versions were kept in vX.Y.Z subdirectory of that directory.\n\nIf we tweak that slightly to \"all versions are kept in vX.Y.Z\nsubdirectory, and the root version is simply a symlink or redirect to\nthe latest vX.Y.Z\", then there is no deletion required. The pusher is\nalways adding new versions, and updating a link[1].\n\nBut even if it would be sufficient for this use case, kup developers\nmay not want such a half-implemented scheme in their protocol.\n\n-Peff\n\n[1] There is a slight complication that the subdirectories live _inside_\n of the root directory, so it is not implementable with a single\n symlink. You could get around that with a few clever http redirects.\n"},{"id":"184387","messageId":"20120210200401.GB5504@sigill.intra.peff.net","threadId":"29568","inReplyTo":"7vmx8rtu3e.fsf@alter.siamese.dyndns.org","subject":"Re: Git documentation at kernel.org","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-10T20:04:01Z","receivedAt":"2012-02-10T20:04:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 09, 2012 at 04:23:01PM -0800, Junio C Hamano wrote:\n\n> It might be a workable short term workaround to redirect\n> \n> http://www.kernel.org/pub/software/scm/git/docs/$anything\n> \n> to\n> \n> http://schacon.github.com/git/$anything\n> \n> although that would not give you an access to the list of documentations\n> for older releases, e.g.\n> \n> http://www.kernel.org/pub/software/scm/git/docs/v1.6.0/git.html\n\nIf there is interest in this, we would be happy to host the\ndocumentation. Let me know if that is the case, and we can give it a\nmuch better URL than schacon.github.com. However, I tend to think that\nsince the project is hosted[1] at kernel.org, the official documentation\nsite should be there as well.\n\n-Peff\n\n[1] Of course, git being git, it is not really hosted _anywhere_ in\n particular. But convention thus far has said that the kernel.org\n repository is the official one.\n"},{"id":"184389","messageId":"7vhayyphlw.fsf@alter.siamese.dyndns.org","threadId":"29568","inReplyTo":"20120210195736.GA5381@thunk.org","subject":"Re: Git documentation at kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-10T20:18:35Z","receivedAt":"2012-02-10T20:18:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ted Ts'o writes:\n\n> How about this as something *way* simpler? Define a way of marking\n> the top of a particular directory hierarchy as a tree. Then the\n> *only* way of updating that tree is all or nothing. That is, someone\n> submits a signed tarball; then after the signed tarball has its\n> signature checked, it gets unpacked into a dir.new, and then we rename\n> dir to dir.old, rename dir.new to dir, and then dir.old gets removed.\n>\n> That way there's no conflicts between directories that are managed via\n> the kup-servers PUT and DELETE commands, and those where they get\n> uploaded as a single tarball to create or replace a specific directory\n> hierarcy, or which can be deleted only as a entire directory hierarcy.\n>\n> What do you think?\n\nThat would not work very well without changing the historical directory\nstructure (which I think was the point of this discussion \"please keep\nthese stale links alive\").\n\nThe toplevel index.html in the pub/software/scm/git/docs/ directory and\nits pointees were the set of docs for the latest version, and older\nversions were rooted at pub/software/scm/git/docs/vX.Y.Z/. Links that\npoint at software/scm/git/docs/git-cat-file.html still need to work, and\nthe path needs to be updatable without having to include the preformatted\ndocumentation for all the historical versions in the same tarball.\n"},{"id":"184397","messageId":"20120210212030.GD5381@thunk.org","threadId":"29568","inReplyTo":"7vhayyphlw.fsf@alter.siamese.dyndns.org","subject":"Re: Git documentation at kernel.org","fromName":"Ted Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2012-02-10T21:20:30Z","receivedAt":"2012-02-10T21:20:30Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Feb 10, 2012 at 12:18:35PM -0800, Junio C Hamano wrote:\n> That would not work very well without changing the historical directory\n> structure (which I think was the point of this discussion \"please keep\n> these stale links alive\").\n> \n> The toplevel index.html in the pub/software/scm/git/docs/ directory and\n> its pointees were the set of docs for the latest version, and older\n> versions were rooted at pub/software/scm/git/docs/vX.Y.Z/. Links that\n> point at software/scm/git/docs/git-cat-file.html still need to work, and\n> the path needs to be updatable without having to include the preformatted\n> documentation for all the historical versions in the same tarball.\n\nHmm... good point. That does make it hard. I could imagine making it\nwork by having separate hierarchies, and then using apache rewrite\nrules so that anything that doesn't begin with vX.Y.Z in the top level\nof software/scm/git/docs/* gets redirected to LATEST/*, where LATEST is\na symlink that is managed via kup.\n\nI don't know if the k.org folks would consider that acceptable, though.\n\n \t \t \t \t \t - Ted\n"},{"id":"184404","messageId":"7vsjiinzc8.fsf@alter.siamese.dyndns.org","threadId":"29568","inReplyTo":"20120210212030.GD5381@thunk.org","subject":"Re: Git documentation at kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-10T21:38:31Z","receivedAt":"2012-02-10T21:38:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ted Ts'o writes:\n\n> Hmm... good point. That does make it hard. I could imagine making it\n> work by having separate hierarchies, and then using apache rewrite\n> rules so that anything that doesn't begin with vX.Y.Z in the top level\n> of software/scm/git/docs/* gets redirected to LATEST/*, where LATEST is\n> a symlink that is managed via kup.\n\nWe could move vX.Y.Zs out of scm/git/docs/ hierarchy. The existing links\nfrom external sites rarely point at a documentation page of a specific\nversion, I suspect.\n\nPeople can be trained to look at scm/git/old-docs/vX.Y.Z when they want to\nsee how older command set looked like, even those who know that in olden\ndays they would have consulted scm/git/docs/vX.Y.Z for that information;\nthey are much less of a problem than existing pages whose links want to\nstay working.\n"},{"id":"184531","messageId":"vpqehtz909k.fsf@bauges.imag.fr","threadId":"29568","inReplyTo":"20120210200401.GB5504@sigill.intra.peff.net","subject":"Re: Git documentation at kernel.org","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-02-12T22:04:23Z","receivedAt":"2012-02-12T22:04:23Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jeff King writes:\n\n> If there is interest in this, we would be happy to host the\n> documentation. Let me know if that is the case, and we can give it a\n> much better URL than schacon.github.com. However, I tend to think that\n> since the project is hosted[1] at kernel.org, the official documentation\n> site should be there as well.\n\nkernel.org is probably the most \"official\" place for developers, but for\nGit users, http://git-scm.com/ is most likely the best entry point. If\nit were not for historical reasons, I think http://git-scm.com/docs/ or\nso would be the most natural URL to host official docs.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"184532","messageId":"20120212222508.GA25619@sigill.intra.peff.net","threadId":"29568","inReplyTo":"vpqehtz909k.fsf@bauges.imag.fr","subject":"Re: Git documentation at kernel.org","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-12T22:25:08Z","receivedAt":"2012-02-12T22:25:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 12, 2012 at 11:04:23PM +0100, Matthieu Moy wrote:\n\n> Jeff King writes:\n> \n> > If there is interest in this, we would be happy to host the\n> > documentation. Let me know if that is the case, and we can give it a\n> > much better URL than schacon.github.com. However, I tend to think that\n> > since the project is hosted[1] at kernel.org, the official documentation\n> > site should be there as well.\n> \n> kernel.org is probably the most \"official\" place for developers, but for\n> Git users, http://git-scm.com/ is most likely the best entry point. If\n> it were not for historical reasons, I think http://git-scm.com/docs/ or\n> so would be the most natural URL to host official docs.\n\nGood point. That is probably the best place to host it.\n\nAs far as historical reasons, perhaps the right answer is to put the\ndocumentation where it makes sense to go _now_, and ask kernel.org to\nissue http redirects for http://kernel.org/pub/software/scm/git/docs.\n\n-Peff\n"},{"id":"184533","messageId":"CAP2yMa+2E6101fe3Z2WTCfuGnq17WT7nDUQr7PVH6_YKRnNifw@mail.gmail.com","threadId":"29568","inReplyTo":"20120212222508.GA25619@sigill.intra.peff.net","subject":"Re: Git documentation at kernel.org","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2012-02-12T23:04:59Z","receivedAt":"2012-02-12T23:04:59Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Sun, Feb 12, 2012 at 2:25 PM, Jeff King wrote:\n>> kernel.org is probably the most \"official\" place for developers, but for\n>> Git users, http://git-scm.com/ is most likely the best entry point. If\n>> it were not for historical reasons, I think http://git-scm.com/docs/ or\n>> so would be the most natural URL to host official docs.\n>\n> Good point. That is probably the best place to host it.\n>\n> As far as historical reasons, perhaps the right answer is to put the\n> documentation where it makes sense to go _now_, and ask kernel.org to\n> issue http redirects for http://kernel.org/pub/software/scm/git/docs.\n\nI would be happy to set this up. I'm currently in the process of\nrevamping the website and this is one of the things I'm planning on\ndoing anyways - not just hosting the generated docs, but also making\nthem searchable and whatnot.\n\nActually, as long as I'm on this, what do people think about git-scm\nhosting the wiki as well? As far as I can tell, it was down for\nmonths and now it's back in some sort of weird read-only state. If I\nimported everything into a different wiki and hosted it on git-scm\nwould that be acceptable?\n\nAlso, something that I realized I am not willing to maintain any more\nis the Git Community Book. It was an experiment at reorganizing some\nof the docs, but instead I spent my time on Pro Git, which is CC\nlicensed. Would anyone object to me removing the community book from\nthe git-scm site and more tightly integrating the Pro Git content?\nIt's more up to date and better content, I feel - I would rather have\none book to maintain than two. However, since it is a commercial\nproduct (albeit a Creative Commons licensed one), I wasn't sure if\npeople would have an issue with it.\n\nScott\n"},{"id":"184535","messageId":"20120213003024.GA25794@sigill.intra.peff.net","threadId":"29568","inReplyTo":"CAP2yMa+2E6101fe3Z2WTCfuGnq17WT7nDUQr7PVH6_YKRnNifw@mail.gmail.com","subject":"Re: Git documentation at kernel.org","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-13T00:30:24Z","receivedAt":"2012-02-13T00:30:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 12, 2012 at 03:04:59PM -0800, Scott Chacon wrote:\n\n> > Good point. That is probably the best place to host it.\n> >\n> > As far as historical reasons, perhaps the right answer is to put the\n> > documentation where it makes sense to go _now_, and ask kernel.org to\n> > issue http redirects for http://kernel.org/pub/software/scm/git/docs.\n> \n> I would be happy to set this up. I'm currently in the process of\n> revamping the website and this is one of the things I'm planning on\n> doing anyways - not just hosting the generated docs, but also making\n> them searchable and whatnot.\n\nThat sounds great to me. I'd like to be link-compatible with the old\nkernel.org docs section (even if through redirects) so that old links\nwork (assuming kernel.org gives us a wholesale redirect). Which means\nimporting all of the docs for released versions. I don't know if the old\nkernel.org doc tree was saved anywhere, but if I understand correctly,\nthey are identical to what's in the \"git-htmldocs\" repository (which I\n_thought_ Junio wasn't going to keep updating, but it seems pretty up to\ndate).\n\n> Actually, as long as I'm on this, what do people think about git-scm\n> hosting the wiki as well? As far as I can tell, it was down for\n> months and now it's back in some sort of weird read-only state. If I\n> imported everything into a different wiki and hosted it on git-scm\n> would that be acceptable?\n\nI'd really love it if the wiki was converted to something that was\ngit-backed. But I suspect some people might complain about switching off\nof mediawiki. IIRC, gollum supports some mediawiki syntax, but I don't\nknow how much conversion work there would be.\n\n> Also, something that I realized I am not willing to maintain any more\n> is the Git Community Book. It was an experiment at reorganizing some\n> of the docs, but instead I spent my time on Pro Git, which is CC\n> licensed. Would anyone object to me removing the community book from\n> the git-scm site and more tightly integrating the Pro Git content?\n> It's more up to date and better content, I feel - I would rather have\n> one book to maintain than two. However, since it is a commercial\n> product (albeit a Creative Commons licensed one), I wasn't sure if\n> people would have an issue with it.\n\nI can't remember anybody mentioning the Git Community Book here in the\npast few years. New users typically come with a \"I read this in Pro Git\nand I don't understand...\" question, and experienced users recommend or\nlink to Pro Git. So I think the world would be a less confusing place\nwith just the one source.\n\n-Peff\n"},{"id":"184537","messageId":"7vmx8nju1k.fsf@alter.siamese.dyndns.org","threadId":"29568","inReplyTo":"20120213003024.GA25794@sigill.intra.peff.net","subject":"Re: Git documentation at kernel.org","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-13T03:23:19Z","receivedAt":"2012-02-13T03:23:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> That sounds great to me. I'd like to be link-compatible with the old\n> kernel.org docs section (even if through redirects) so that old links\n> work (assuming kernel.org gives us a wholesale redirect). Which means\n> importing all of the docs for released versions. I don't know if the old\n> kernel.org doc tree was saved anywhere, but if I understand correctly,\n> they are identical to what's in the \"git-htmldocs\" repository (which I\n> _thought_ Junio wasn't going to keep updating, but it seems pretty up to\n> date).\n\nI have been updating htmldocs/manpages repositories on \"unless I forget\"\nbasis every time the public 'master' gets updated, so they are updated as\nfrequently as they used to back when they were autogenerated, \"unless I\nforget\".\n\nBut the contents of htmldocs does _not_ match what used to be at k.org in\nthat its git.html does not have links to documentation pages for older\nreleases, iow, formatted without \"stalenotes\" defined.\n\nThis is because formatting with \"stalenotes\" needs to make an assumption\non the filesystem layout that I cannot enforce to the users of htmldocs\nrepository. They will get one tarball for one version, and it is up to\nthem where they extract these tarballs. They need to extract the tarball\nof an older release vX.Y.Z in vX.Y.Z subdirectory next to the git.html of\nthe latest living document to match the layout, but otherwise the links\ncreated by \"stalenotes\" will become dangling.\n"},{"id":"184568","messageId":"1329146158.13544.6.camel@i5.mricon.com","threadId":"29568","inReplyTo":"20120212222508.GA25619@sigill.intra.peff.net","subject":"Re: Git documentation at kernel.org","fromName":"Konstantin Ryabitsev","fromEmail":"mricon@kernel.org","sentAt":"2012-02-13T15:15:58Z","receivedAt":"2012-02-13T15:15:58Z","isPatch":false,"sender":{"key":"mricon@kernel.org","avatar":"https://gravatar.com/avatar/d74ca8eb882d19f551bebba2b75663fd9032ab8590103b23ec87236dcd7f349b?d=mp&s=160"},"body":"On Sun, 2012-02-12 at 17:25 -0500, Jeff King wrote:\n> As far as historical reasons, perhaps the right answer is to put the\n> documentation where it makes sense to go _now_, and ask kernel.org to\n> issue http redirects for http://kernel.org/pub/software/scm/git/docs. \n\nI think that should be fine, unless John objects. The easiest would be\nto preserve the same directory structure, so we do a dir-level redirect\ninstead of creating one-off redirects for each page.\n\nBest,\n-- \nKonstantin Ryabitsev\nSystems Administrator, Kernel.org\nMontréal, Québec\n"},{"id":"184711","messageId":"20120214221525.GD24802@sigill.intra.peff.net","threadId":"29568","inReplyTo":"7vmx8nju1k.fsf@alter.siamese.dyndns.org","subject":"Re: Git documentation at kernel.org","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-14T22:15:25Z","receivedAt":"2012-02-14T22:15:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Feb 12, 2012 at 07:23:19PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > That sounds great to me. I'd like to be link-compatible with the old\n> > kernel.org docs section (even if through redirects) so that old links\n> > work (assuming kernel.org gives us a wholesale redirect). Which means\n> > importing all of the docs for released versions. I don't know if the old\n> > kernel.org doc tree was saved anywhere, but if I understand correctly,\n> > they are identical to what's in the \"git-htmldocs\" repository (which I\n> > _thought_ Junio wasn't going to keep updating, but it seems pretty up to\n> > date).\n> [...]\n> But the contents of htmldocs does _not_ match what used to be at k.org in\n> that its git.html does not have links to documentation pages for older\n> releases, iow, formatted without \"stalenotes\" defined.\n\nAh, that makes sense. We might have to just rebuild the old versions\nwith stalenotes, then (our doc toolchain is so finicky that I worry\nabout minor incompatibilities in building old versions with a newer\ntoolchain, but it is probably good enough).\n\n-Peff\n"}]}