{"thread":{"id":"19363","subject":"Removing the trailing \"/.git\" from gitweb display?","startedAt":"2009-05-15T20:49:50Z","lastAt":"2009-05-16T08:14:27Z","messageCount":8,"participants":["Timur Tabi","J.H.","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"114032","messageId":"ed82fe3e0905151349k15f040aej30dbec82037e9d76@mail.gmail.com","threadId":"19363","inReplyTo":null,"subject":"Removing the trailing \"/.git\" from gitweb display?","fromName":"Timur Tabi","fromEmail":"timur@freescale.com","sentAt":"2009-05-15T20:49:50Z","receivedAt":"2009-05-15T20:49:50Z","isPatch":false,"sender":{"key":"timur@freescale.com","avatar":null},"body":"I noticed that most gitweb pages show their repositories like this:\n\nbluetooth/bluez-gnome.git \tBluetooth applications for ... \tMarcel Holtmann\nbluetooth/bluez-hcidump.git \tBluetooth packet analyzer \tMarcel Holtmann\nbluetooth/bluez.git \tBluetooth protocol stack for ... \tMarcel Holtmann\n\nHowever, mine looks like this:\n\nalsa.1862/.git\t8610 audio: fabric driver uses wrong DMA channels for... \tTimur\nalsa.2598/.git\t8610 audio: migrate ASoC V2 drivers to mainline\tTimur\nalsa.3313/.git\tIntroduce spin_event_timeout()\tTimur\n\nNotice how my repositories have a trailing \"/.git\" to them?  How do I\nget rid of that?\n\nMy gitweb.conf is:\n\n$projectroot = '/home/b04825/git/';\n$site_name = \"Timur Tabi's git repositories\";\n$home_link = $my_uri;\n@stylesheets = (\"gitweb.css\");\n$favicon = \"git-favicon.png\";\n$logo = \"git-logo.png\";\n$projects_list = '/home/b04825/git/projects_list';\n$projects_list_description_width = 50;\n\nAnd /home/b04825/git/projects_list looks like:\n\nalsa.1862/.git Timur\nalsa.2598/.git Timur\nalsa.3313/.git Timur\n\nI presume the reason why gitweb shows the trailing \"/.git\" is because\nthat's what my projects_list file contains.  However, if I remove the\n\"/.git\" from projects_list, gitweb can't find any repositories.\n\n-- \nTimur Tabi\nLinux kernel developer at Freescale\n"},{"id":"114035","messageId":"4A0DDB4E.8090905@eaglescrag.net","threadId":"19363","inReplyTo":"ed82fe3e0905151349k15f040aej30dbec82037e9d76@mail.gmail.com","subject":"Re: Removing the trailing \"/.git\" from gitweb display?","fromName":"J.H.","fromEmail":"warthog19@eaglescrag.net","sentAt":"2009-05-15T21:14:54Z","receivedAt":"2009-05-15T21:14:54Z","isPatch":false,"sender":{"key":"warthog19@eaglescrag.net","avatar":null},"body":"Your actually barking up two separate trees / issues here.\n\nTimur Tabi wrote:\n> I noticed that most gitweb pages show their repositories like this:\n> \n> bluetooth/bluez-gnome.git \tBluetooth applications for ... \tMarcel Holtmann\n> bluetooth/bluez-hcidump.git \tBluetooth packet analyzer \tMarcel Holtmann\n> bluetooth/bluez.git \tBluetooth protocol stack for ... \tMarcel Holtmann\n\nI'm going to assume you pulled this off of kernel.org, but the basic \nreason here is that we use the <project>.git moniker as a standard to \ndesignate that the underlying directory is a bare git repo.  That's \nreally it there.  We do have a script that wanders our directory \nstructure and looks or directories based on the <project>.git so that's \na bit required from our perspective.\n\n> \n> However, mine looks like this:\n> \n> alsa.1862/.git\t8610 audio: fabric driver uses wrong DMA channels for... \tTimur\n> alsa.2598/.git\t8610 audio: migrate ASoC V2 drivers to mainline\tTimur\n> alsa.3313/.git\tIntroduce spin_event_timeout()\tTimur\n\nIf your doing that, then your putting a full git tree into gitweb as \nopposed to a bare repo.  I would suggest only putting a bare repo.\n\n> \n> Notice how my repositories have a trailing \"/.git\" to them?  How do I\n> get rid of that?\n> \n> My gitweb.conf is:\n> \n> $projectroot = '/home/b04825/git/';\n> $site_name = \"Timur Tabi's git repositories\";\n> $home_link = $my_uri;\n> @stylesheets = (\"gitweb.css\");\n> $favicon = \"git-favicon.png\";\n> $logo = \"git-logo.png\";\n> $projects_list = '/home/b04825/git/projects_list';\n> $projects_list_description_width = 50;\n> \n> And /home/b04825/git/projects_list looks like:\n> \n> alsa.1862/.git Timur\n> alsa.2598/.git Timur\n> alsa.3313/.git Timur\n> \n> I presume the reason why gitweb shows the trailing \"/.git\" is because\n> that's what my projects_list file contains.  However, if I remove the\n> \"/.git\" from projects_list, gitweb can't find any repositories.\n"},{"id":"114036","messageId":"20090515211611.27697.82605.stgit@localhost.localdomain","threadId":"19363","inReplyTo":"ed82fe3e0905151349k15f040aej30dbec82037e9d76@mail.gmail.com","subject":"[PATCH] gitweb: Document that gitweb deals with bare repositories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-15T21:17:57Z","receivedAt":"2009-05-15T21:17:57Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Add reminders to gitweb/README and gitweb/INSTALL that gitweb works\nwith bare repositories.  While it might be obvious to us, it is not\napparently as evident for newcomers.\n\nSigned-off-by: Jakub Narebski <jnareb@gmail.com>\n---\nTimur Tabi wrote:\n\n> I noticed that most gitweb pages show their repositories like this:\n> \n> bluetooth/bluez-gnome.git \tBluetooth applications for ... \tMarcel Holtmann\n> bluetooth/bluez-hcidump.git \tBluetooth packet analyzer \tMarcel Holtmann\n> bluetooth/bluez.git\t\tBluetooth protocol stack for... Marcel Holtmann\n> \n> However, mine looks like this:\n> \n> alsa.1862/.git  8610 audio: fabric driver uses wrong DMA channels for... \tTimur\n> alsa.2598/.git  8610 audio: migrate ASoC V2 drivers to mainline\tTimur\n> alsa.3313/.git  Introduce spin_event_timeout()\tTimur\n> \n> Notice how my repositories have a trailing \"/.git\" to them?  How do I\n> get rid of that?\n> \n> My gitweb.conf is:\n> \n> $projectroot = '/home/b04825/git/';\n> $site_name = \"Timur Tabi's git repositories\";\n> $home_link = $my_uri;\n> @stylesheets = (\"gitweb.css\");\n> $favicon = \"git-favicon.png\";\n> $logo = \"git-logo.png\";\n> $projects_list = '/home/b04825/git/projects_list';\n> $projects_list_description_width = 50;\n> \n> And /home/b04825/git/projects_list looks like:\n> \n> alsa.1862/.git Timur\n> alsa.2598/.git Timur\n> alsa.3313/.git Timur\n> \n> I presume the reason why gitweb shows the trailing \"/.git\" is because\n> that's what my projects_list file contains.  However, if I remove the\n> \"/.git\" from projects_list, gitweb can't find any repositories.\n\nDoes this explanation help?\n\n gitweb/INSTALL |   14 ++++++++++++++\n gitweb/README  |   12 +++++++-----\n 2 files changed, 21 insertions(+), 5 deletions(-)\n\ndiff --git a/gitweb/INSTALL b/gitweb/INSTALL\nindex 18c9ce3..f43e233 100644\n--- a/gitweb/INSTALL\n+++ b/gitweb/INSTALL\n@@ -127,6 +127,20 @@ GITWEB_CONFIG file:\n Gitweb repositories\n -------------------\n \n+- Gitweb deals with bare repositories, which means that gitweb scans for\n+  (in the case where $projects_list is a directory to search for\n+  repositories) or has to be provided with list of (in the case where\n+  $projects_list is a text file) bare repositories, i.e. $GIT_DIR for\n+  each repository. The consequence of that is the fact that if you use\n+  gitweb to view non-bare repository named 'repo' then gitweb would show\n+  (or would have to be provided with) 'repo/.git'.\n+\n+  If you want to view a buch of non-bare repositories in gitweb but want\n+  them named 'repo.git' as is the standard for bare repositories, you\n+  can as a workaround populare $projectroot / $project_list with\n+  symbolic links to $GIT_DIR of each project you want to publish (have\n+  shown) in gitweb.\n+\n - By default all git repositories under projectroot are visible and\n   available to gitweb. The list of projects is generated by default by\n   scanning the projectroot directory for git repositories (for object\ndiff --git a/gitweb/README b/gitweb/README\nindex ccda890..a61fa2f 100644\n--- a/gitweb/README\n+++ b/gitweb/README\n@@ -34,10 +34,11 @@ You can specify the following configuration variables when building GIT:\n  * GITWEB_LIST\n    Points to a directory to scan for projects (defaults to project root\n    if not set / if empty) or to a file with explicit listing of projects\n-   (together with projects' ownership). See \"Generating projects list\n-   using gitweb\" in INSTALL file for gitweb to find out how to generate\n-   such file from scan of a directory. [No default, which means use root\n-   directory for projects]\n+   (together with projects' ownership). Note that gitweb deals with bare\n+   repositories; it shows/uses $GIT_DIR for each repository. See also\n+   \"Generating projects list using gitweb\" in INSTALL file for gitweb to\n+   find out how to generate such file from scan of a directory. \n+   [No default, which means use root directory for projects]\n  * GITWEB_EXPORT_OK\n    Show repository only if this file exists (in repository).  Only\n    effective if this variable evaluates to true.  [No default / Not set]\n@@ -153,7 +154,8 @@ not include variables usually directly set during build):\n    Absolute filesystem path which will be prepended to project path;\n    the path to repository is $projectroot/$project.  Set to\n    $GITWEB_PROJECTROOT during installation.  This variable have to be\n-   set correctly for gitweb to find repositories.\n+   set correctly for gitweb to find repositories.  (Note that gitweb deals\n+   with bare repositories.)\n  * $projects_list\n    Source of projects list, either directory to scan, or text file\n    with list of repositories (in the \"<URI-encoded repository path> SP\n"},{"id":"114037","messageId":"4A0DDD94.1010901@freescale.com","threadId":"19363","inReplyTo":"20090515211611.27697.82605.stgit@localhost.localdomain","subject":"Re: [PATCH] gitweb: Document that gitweb deals with bare repositories","fromName":"Timur Tabi","fromEmail":"timur@freescale.com","sentAt":"2009-05-15T21:24:36Z","receivedAt":"2009-05-15T21:24:36Z","isPatch":true,"sender":{"key":"timur@freescale.com","avatar":null},"body":"Jakub Narebski wrote:\n\n> Does this explanation help?\n\nYes, it does, but I wish it weren't true.  I don't see why gitweb can't be enhanced to support non-bare repositories without using symlinks or other hackery.\n\nTo avoid the overhead of gitweb scanning all of my repositories for other respitories, I use a packages_list, which is automatically recreated whenever I add a new repo.  However, I think having to create a shadow bare repository with a cron job to keep it more-or-less update is wrong.\n\nJust my two cents.\n\n-- \nTimur Tabi\nLinux kernel developer at Freescale\n"},{"id":"114039","messageId":"200905152336.49319.jnareb@gmail.com","threadId":"19363","inReplyTo":"4A0DDD94.1010901@freescale.com","subject":"Re: [PATCH] gitweb: Document that gitweb deals with bare repositories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-15T21:36:48Z","receivedAt":"2009-05-15T21:36:48Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 15 May 2009, Timur Tabi wrote:\n> Jakub Narebski wrote:\n> \n> > Does this explanation help?\n> \n> Yes, it does, but I wish it weren't true.  I don't see why gitweb\n> can't be enhanced to support non-bare repositories without using\n> symlinks or other hackery.  \n\nActually the patch I have sent is not formulated as well as I wish.\nThat is why I didn't send it earlier (and I probably should have marked\nit as RFC; still it is better than now).\n\nGitweb can deal with non-bare repositories. It is only that because \ngitweb is not interested in working area, it shows $GIT_DIR (path to \nrepository itself) as name/path to repository. Therefore repo/.git\nfor non-bare repositories, because it is repository itself that matters.\n\n> \n> To avoid the overhead of gitweb scanning all of my repositories for\n> other respitories, I use a packages_list, which is automatically\n> recreated whenever I add a new repo.  However, I think having to\n> create a shadow bare repository with a cron job to keep it\n> more-or-less update is wrong.    \n\nIf you use gitweb only for yourself, take a look at git-instaweb\n\nIf you provide access for others, i.e. if those repositories shown in \ngitweb are public repositories, it is much better to use bare \nrepositories for that.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"114043","messageId":"ed82fe3e0905151521m64df542eifca87073c4360fbf@mail.gmail.com","threadId":"19363","inReplyTo":"200905152336.49319.jnareb@gmail.com","subject":"Re: [PATCH] gitweb: Document that gitweb deals with bare repositories","fromName":"Timur Tabi","fromEmail":"timur@freescale.com","sentAt":"2009-05-15T22:21:42Z","receivedAt":"2009-05-15T22:21:42Z","isPatch":true,"sender":{"key":"timur@freescale.com","avatar":null},"body":"On Fri, May 15, 2009 at 4:36 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n> Gitweb can deal with non-bare repositories. It is only that because\n> gitweb is not interested in working area, it shows $GIT_DIR (path to\n> repository itself) as name/path to repository. Therefore repo/.git\n> for non-bare repositories, because it is repository itself that matters.\n\nI understand that, but why does gitweb have to punish me because I\ngive it more than it cares about?\n\n> If you provide access for others, i.e. if those repositories shown in\n> gitweb are public repositories, it is much better to use bare\n> repositories for that.\n\nWhy?  What difference does it make if they clone directly from my\nworking tree, instead of some shadow repository?\n\n-- \nTimur Tabi\nLinux kernel developer at Freescale\n"},{"id":"114055","messageId":"7vab5dsrur.fsf@alter.siamese.dyndns.org","threadId":"19363","inReplyTo":"ed82fe3e0905151521m64df542eifca87073c4360fbf@mail.gmail.com","subject":"Re: [PATCH] gitweb: Document that gitweb deals with bare repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-05-16T02:29:16Z","receivedAt":"2009-05-16T02:29:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Timur Tabi <timur@freescale.com> writes:\n\n>> If you provide access for others, i.e. if those repositories shown in\n>> gitweb are public repositories, it is much better to use bare\n>> repositories for that.\n>\n> Why?  What difference does it make if they clone directly from my\n> working tree, instead of some shadow repository?\n\nThere is none.\n\nEven though I would not personally publish the live repository I\npersonally work in via gitweb, I do not think that has to be a holy rule\nnot to be broken by anybody.  Some people may want to show state of a live\ntree, and other people may be willing to peek into it.  I do not think it\nis worth spending excess effort beyond giving one educational advice like\nJakub did to prevent them from doing so.  It's their choice.  While they\nmay have to live with the consequence of such an arrangement, other people\nwon't be harmed (I do not think it is such a big deal for them to deal\nwith the fallout either).\n\nI personally would not mind peeking into such a gitweb, but I would really\nhesitate to fetch from a repository that is known to be live.  The commits\nI would see there right now are not likely to be in the finished form (the\nlive repository owner may want to amend them).  The repository owner may\npromise \"I'll keep them stable and never amend\", but that is worse, at\nleast from my point of view, as nobody is perfect and the resulting\nhistory in such a live repository is bound to be full of crufts I'd rather\nnot have to wade through.\n\nIt is a very useful coalmine canary to see the path in gitweb ending with\nslash dot git like /home/tt/foo/.git, not /home/tt/foo.git, for me to be\nable to tell which is which.  If it is a bare repository without a work\ntree, as long as the repository owner has graduated the CVS mentality and\nacquired a good habit of not pushing things too hastily, there is a chance\nthat the history I would see there is reviewed by the author and cleaned\nup to be presentable.\n"},{"id":"114082","messageId":"200905161014.28521.jnareb@gmail.com","threadId":"19363","inReplyTo":"ed82fe3e0905151521m64df542eifca87073c4360fbf@mail.gmail.com","subject":"Re: [PATCH] gitweb: Document that gitweb deals with bare repositories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-16T08:14:27Z","receivedAt":"2009-05-16T08:14:27Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 16 May 2009, Timur Tabi wrote:\n> On Fri, May 15, 2009 at 4:36 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n\n> > Gitweb can deal with non-bare repositories. It is only that because\n> > gitweb is not interested in working area, it shows $GIT_DIR (path to\n> > repository itself) as name/path to repository. Therefore repo/.git\n> > for non-bare repositories, because it is repository itself that matters.\n> \n> I understand that, but why does gitweb have to punish me because I\n> give it more than it cares about?\n\nGitweb doesn't punish you for using non-bare repositories. Gitweb is\njust consistent: all that matters to gitweb is repository itself\n($GIT_DIR), therefore it uses 'project/.git' as a project name for\nnon-bare, because this is $GIT_DIR for it.\n\nBesides, why do you care that your non-bare repositories have\n'project/.git' as their name? As Junio wrote it is a good idea to be\nable to distinguish between bare and non-bare repositories. Perhaps\nI should remove description of workaround from the patch...\n\n\nAnyway I'd rather not complicate further 6336 lines long \ngitweb/gitweb.perl, one of largest scripts in git repository. One would\nhave to add stripping s!/\\.git$!! from repository path (project name)\non display, and do additional check for $path/.git when checking if\nwhat we were given looks like git repository.\n\n> \n> > If you provide access for others, i.e. if those repositories shown in\n> > gitweb are public repositories, it is much better to use bare\n> > repositories for that.\n> \n> Why?  What difference does it make if they clone directly from my\n> working tree, instead of some shadow repository?\n\nWell, best practice is to not change (rewrite) published history. This\nmeans that you very strongly shouldn't even use \"git commit --amend\",\nneverthemind \"git rebase\" and reordering patches and squashing bugfixes\nusing \"git rebase --interactive\" (or other tools like StGit or Guilt)\non the branches you meant to share. Because otherwise you would seriously\ninconvenience developers which base their work your work on\nshared/published branch.\n\nAlso you should take into account that if you publish your working,\nnon-bare repositories, all your branches are visible to the world.\nSo unless you tell other developers which branches are meant to share,\nand which are not, you would have trouble with working on topic branches.\nAnd for more complicated features best practices demand that you do them\nas a series of commits rather than one big complicated patch on feature\nbranch, and it is hard to create a perfect, or just good (so it doesn't\nlook like \"A, B, oops fix A, C, oops revert B, oops fix C\"), series of\ncommits on first try. And there is also bit of complication for other\ndevelopers if you, as best practices tell you should, delete no longer\nused (merged in) short term feature branches; this would require pruning\nremote-tracking branches by other developers.\n\n\nSo unless you work by yourself (and then see git-instaweb), it is really\nbetter to have separate public publishing repository, which is bare.\n\n-- \nJakub Narebski\nPoland\n"}]}