Removing the trailing "/.git" from gitweb display?

Removing the trailing "/.git" from gitweb display?

[Timur Tabi]

I noticed that most gitweb pages show their repositories like this:

bluetooth/bluez-gnome.git 	Bluetooth applications for ... 	Marcel Holtmann
bluetooth/bluez-hcidump.git 	Bluetooth packet analyzer 	Marcel Holtmann
bluetooth/bluez.git 	Bluetooth protocol stack for ... 	Marcel Holtmann

However, mine looks like this:

alsa.1862/.git	8610 audio: fabric driver uses wrong DMA channels for... 	Timur
alsa.2598/.git	8610 audio: migrate ASoC V2 drivers to mainline	Timur
alsa.3313/.git	Introduce spin_event_timeout()	Timur

Notice how my repositories have a trailing "/.git" to them?  How do I
get rid of that?

My gitweb.conf is:

$projectroot = '/home/b04825/git/';
$site_name = "Timur Tabi's git repositories";
$home_link = $my_uri;
@stylesheets = ("gitweb.css");
$favicon = "git-favicon.png";
$logo = "git-logo.png";
$projects_list = '/home/b04825/git/projects_list';
$projects_list_description_width = 50;

And /home/b04825/git/projects_list looks like:

alsa.1862/.git Timur
alsa.2598/.git Timur
alsa.3313/.git Timur

I presume the reason why gitweb shows the trailing "/.git" is because
that's what my projects_list file contains.  However, if I remove the
"/.git" from projects_list, gitweb can't find any repositories.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Removing the trailing "/.git" from gitweb display?

[J.H.]

Your actually barking up two separate trees / issues here.

Timur Tabi wrote:
> I noticed that most gitweb pages show their repositories like this:
> 
> bluetooth/bluez-gnome.git 	Bluetooth applications for ... 	Marcel Holtmann
> bluetooth/bluez-hcidump.git 	Bluetooth packet analyzer 	Marcel Holtmann
> bluetooth/bluez.git 	Bluetooth protocol stack for ... 	Marcel Holtmann

I'm going to assume you pulled this off of kernel.org, but the basic 
reason here is that we use the <project>.git moniker as a standard to 
designate that the underlying directory is a bare git repo.  That's 
really it there.  We do have a script that wanders our directory 
structure and looks or directories based on the <project>.git so that's 
a bit required from our perspective.

> 
> However, mine looks like this:
> 
> alsa.1862/.git	8610 audio: fabric driver uses wrong DMA channels for... 	Timur
> alsa.2598/.git	8610 audio: migrate ASoC V2 drivers to mainline	Timur
> alsa.3313/.git	Introduce spin_event_timeout()	Timur

If your doing that, then your putting a full git tree into gitweb as 
opposed to a bare repo.  I would suggest only putting a bare repo.

> 
> Notice how my repositories have a trailing "/.git" to them?  How do I
> get rid of that?
> 
> My gitweb.conf is:
> 
> $projectroot = '/home/b04825/git/';
> $site_name = "Timur Tabi's git repositories";
> $home_link = $my_uri;
> @stylesheets = ("gitweb.css");
> $favicon = "git-favicon.png";
> $logo = "git-logo.png";
> $projects_list = '/home/b04825/git/projects_list';
> $projects_list_description_width = 50;
> 
> And /home/b04825/git/projects_list looks like:
> 
> alsa.1862/.git Timur
> alsa.2598/.git Timur
> alsa.3313/.git Timur
> 
> I presume the reason why gitweb shows the trailing "/.git" is because
> that's what my projects_list file contains.  However, if I remove the
> "/.git" from projects_list, gitweb can't find any repositories.

[PATCH] gitweb: Document that gitweb deals with bare repositories

[Jakub Narebski]

Add reminders to gitweb/README and gitweb/INSTALL that gitweb works
with bare repositories.  While it might be obvious to us, it is not
apparently as evident for newcomers.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Timur Tabi wrote:

> I noticed that most gitweb pages show their repositories like this:
> 
> bluetooth/bluez-gnome.git 	Bluetooth applications for ... 	Marcel Holtmann
> bluetooth/bluez-hcidump.git 	Bluetooth packet analyzer 	Marcel Holtmann
> bluetooth/bluez.git		Bluetooth protocol stack for... Marcel Holtmann
> 
> However, mine looks like this:
> 
> alsa.1862/.git  8610 audio: fabric driver uses wrong DMA channels for... 	Timur
> alsa.2598/.git  8610 audio: migrate ASoC V2 drivers to mainline	Timur
> alsa.3313/.git  Introduce spin_event_timeout()	Timur
> 
> Notice how my repositories have a trailing "/.git" to them?  How do I
> get rid of that?
> 
> My gitweb.conf is:
> 
> $projectroot = '/home/b04825/git/';
> $site_name = "Timur Tabi's git repositories";
> $home_link = $my_uri;
> @stylesheets = ("gitweb.css");
> $favicon = "git-favicon.png";
> $logo = "git-logo.png";
> $projects_list = '/home/b04825/git/projects_list';
> $projects_list_description_width = 50;
> 
> And /home/b04825/git/projects_list looks like:
> 
> alsa.1862/.git Timur
> alsa.2598/.git Timur
> alsa.3313/.git Timur
> 
> I presume the reason why gitweb shows the trailing "/.git" is because
> that's what my projects_list file contains.  However, if I remove the
> "/.git" from projects_list, gitweb can't find any repositories.

Does this explanation help?

 gitweb/INSTALL |   14 ++++++++++++++
 gitweb/README  |   12 +++++++-----
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 18c9ce3..f43e233 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -127,6 +127,20 @@ GITWEB_CONFIG file:
 Gitweb repositories
 -------------------
 
+- Gitweb deals with bare repositories, which means that gitweb scans for
+  (in the case where $projects_list is a directory to search for
+  repositories) or has to be provided with list of (in the case where
+  $projects_list is a text file) bare repositories, i.e. $GIT_DIR for
+  each repository. The consequence of that is the fact that if you use
+  gitweb to view non-bare repository named 'repo' then gitweb would show
+  (or would have to be provided with) 'repo/.git'.
+
+  If you want to view a buch of non-bare repositories in gitweb but want
+  them named 'repo.git' as is the standard for bare repositories, you
+  can as a workaround populare $projectroot / $project_list with
+  symbolic links to $GIT_DIR of each project you want to publish (have
+  shown) in gitweb.
+
 - By default all git repositories under projectroot are visible and
   available to gitweb. The list of projects is generated by default by
   scanning the projectroot directory for git repositories (for object
diff --git a/gitweb/README b/gitweb/README
index ccda890..a61fa2f 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -34,10 +34,11 @@ You can specify the following configuration variables when building GIT:
  * GITWEB_LIST
    Points to a directory to scan for projects (defaults to project root
    if not set / if empty) or to a file with explicit listing of projects
-   (together with projects' ownership). See "Generating projects list
-   using gitweb" in INSTALL file for gitweb to find out how to generate
-   such file from scan of a directory. [No default, which means use root
-   directory for projects]
+   (together with projects' ownership). Note that gitweb deals with bare
+   repositories; it shows/uses $GIT_DIR for each repository. See also
+   "Generating projects list using gitweb" in INSTALL file for gitweb to
+   find out how to generate such file from scan of a directory. 
+   [No default, which means use root directory for projects]
  * GITWEB_EXPORT_OK
    Show repository only if this file exists (in repository).  Only
    effective if this variable evaluates to true.  [No default / Not set]
@@ -153,7 +154,8 @@ not include variables usually directly set during build):
    Absolute filesystem path which will be prepended to project path;
    the path to repository is $projectroot/$project.  Set to
    $GITWEB_PROJECTROOT during installation.  This variable have to be
-   set correctly for gitweb to find repositories.
+   set correctly for gitweb to find repositories.  (Note that gitweb deals
+   with bare repositories.)
  * $projects_list
    Source of projects list, either directory to scan, or text file
    with list of repositories (in the "<URI-encoded repository path> SP

Re: [PATCH] gitweb: Document that gitweb deals with bare repositories

[Timur Tabi]

Jakub Narebski wrote:

> Does this explanation help?

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

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

Just my two cents.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [PATCH] gitweb: Document that gitweb deals with bare repositories

[Jakub Narebski]

On Fri, 15 May 2009, Timur Tabi wrote:
> Jakub Narebski wrote:
> 
> > Does this explanation help?
> 
> Yes, 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.  

Actually the patch I have sent is not formulated as well as I wish.
That is why I didn't send it earlier (and I probably should have marked
it as RFC; still it is better than now).

Gitweb can deal with non-bare repositories. It is only that because 
gitweb is not interested in working area, it shows $GIT_DIR (path to 
repository itself) as name/path to repository. Therefore repo/.git
for non-bare repositories, because it is repository itself that matters.

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

If you use gitweb only for yourself, take a look at git-instaweb

If you provide access for others, i.e. if those repositories shown in 
gitweb are public repositories, it is much better to use bare 
repositories for that.

-- 
Jakub Narebski
Poland

Re: [PATCH] gitweb: Document that gitweb deals with bare repositories

[Timur Tabi]

On Fri, May 15, 2009 at 4:36 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Gitweb can deal with non-bare repositories. It is only that because
> gitweb is not interested in working area, it shows $GIT_DIR (path to
> repository itself) as name/path to repository. Therefore repo/.git
> for non-bare repositories, because it is repository itself that matters.

I understand that, but why does gitweb have to punish me because I
give it more than it cares about?

> If you provide access for others, i.e. if those repositories shown in
> gitweb are public repositories, it is much better to use bare
> repositories for that.

Why?  What difference does it make if they clone directly from my
working tree, instead of some shadow repository?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [PATCH] gitweb: Document that gitweb deals with bare repositories

[Junio C Hamano]

Timur Tabi <timur@freescale.com> writes:

>> If you provide access for others, i.e. if those repositories shown in
>> gitweb are public repositories, it is much better to use bare
>> repositories for that.
>
> Why?  What difference does it make if they clone directly from my
> working tree, instead of some shadow repository?

There is none.

Even though I would not personally publish the live repository I
personally work in via gitweb, I do not think that has to be a holy rule
not to be broken by anybody.  Some people may want to show state of a live
tree, and other people may be willing to peek into it.  I do not think it
is worth spending excess effort beyond giving one educational advice like
Jakub did to prevent them from doing so.  It's their choice.  While they
may have to live with the consequence of such an arrangement, other people
won't be harmed (I do not think it is such a big deal for them to deal
with the fallout either).

I personally would not mind peeking into such a gitweb, but I would really
hesitate to fetch from a repository that is known to be live.  The commits
I would see there right now are not likely to be in the finished form (the
live repository owner may want to amend them).  The repository owner may
promise "I'll keep them stable and never amend", but that is worse, at
least from my point of view, as nobody is perfect and the resulting
history in such a live repository is bound to be full of crufts I'd rather
not have to wade through.

It is a very useful coalmine canary to see the path in gitweb ending with
slash dot git like /home/tt/foo/.git, not /home/tt/foo.git, for me to be
able to tell which is which.  If it is a bare repository without a work
tree, as long as the repository owner has graduated the CVS mentality and
acquired a good habit of not pushing things too hastily, there is a chance
that the history I would see there is reviewed by the author and cleaned
up to be presentable.

Re: [PATCH] gitweb: Document that gitweb deals with bare repositories

[Jakub Narebski]

On Sat, 16 May 2009, Timur Tabi wrote:
> On Fri, May 15, 2009 at 4:36 PM, Jakub Narebski <jnareb@gmail.com> wrote:

> > Gitweb can deal with non-bare repositories. It is only that because
> > gitweb is not interested in working area, it shows $GIT_DIR (path to
> > repository itself) as name/path to repository. Therefore repo/.git
> > for non-bare repositories, because it is repository itself that matters.
> 
> I understand that, but why does gitweb have to punish me because I
> give it more than it cares about?

Gitweb doesn't punish you for using non-bare repositories. Gitweb is
just consistent: all that matters to gitweb is repository itself
($GIT_DIR), therefore it uses 'project/.git' as a project name for
non-bare, because this is $GIT_DIR for it.

Besides, why do you care that your non-bare repositories have
'project/.git' as their name? As Junio wrote it is a good idea to be
able to distinguish between bare and non-bare repositories. Perhaps
I should remove description of workaround from the patch...


Anyway I'd rather not complicate further 6336 lines long 
gitweb/gitweb.perl, one of largest scripts in git repository. One would
have to add stripping s!/\.git$!! from repository path (project name)
on display, and do additional check for $path/.git when checking if
what we were given looks like git repository.

> 
> > If you provide access for others, i.e. if those repositories shown in
> > gitweb are public repositories, it is much better to use bare
> > repositories for that.
> 
> Why?  What difference does it make if they clone directly from my
> working tree, instead of some shadow repository?

Well, best practice is to not change (rewrite) published history. This
means that you very strongly shouldn't even use "git commit --amend",
neverthemind "git rebase" and reordering patches and squashing bugfixes
using "git rebase --interactive" (or other tools like StGit or Guilt)
on the branches you meant to share. Because otherwise you would seriously
inconvenience developers which base their work your work on
shared/published branch.

Also you should take into account that if you publish your working,
non-bare repositories, all your branches are visible to the world.
So unless you tell other developers which branches are meant to share,
and which are not, you would have trouble with working on topic branches.
And for more complicated features best practices demand that you do them
as a series of commits rather than one big complicated patch on feature
branch, and it is hard to create a perfect, or just good (so it doesn't
look like "A, B, oops fix A, C, oops revert B, oops fix C"), series of
commits on first try. And there is also bit of complication for other
developers if you, as best practices tell you should, delete no longer
used (merged in) short term feature branches; this would require pruning
remote-tracking branches by other developers.


So unless you work by yourself (and then see git-instaweb), it is really
better to have separate public publishing repository, which is bare.

-- 
Jakub Narebski
Poland

gitweb $export_ok question

[Thomas Amsler]

Hello,

I am trying to get the gitweb $export_ok to  work. According the installation instructions:

Alternatively, you can configure gitweb to only list and allow
viewing of the explicitly exported repositories, via the



GITWEB_EXPORT_OK build configuration variable (or the $export_ok
variable in gitweb config file). If it evaluates to true, gitweb
shows repositories only if this file exists in its object database
(if directory has the magic file named $export_ok).



... I set $export_ok = "true" in my /etc/gitweb.conf file. I don't know what "file" needs to be added to a repository in order for it to show up again in gitweb. I have tried several things, like specifying the file name in /etc/gitweb.con:

$export_ok ="magic-file-name"

etc. but that doesn't seem to work.

What am I doing wrong here?

Re: gitweb $export_ok question

[Jakub Narebski]

Two requests: could you please do not toppost, as it goes against
natural flow of discussion and reading, but rather quote relevant
parts and respond below? It would be good to not try to send HTML
mail, as it is forbidden by VGER anti-SPAM filter, so you trying
to send HTML-formatted email result in me getting two copies: one
with and one without HTML version.

On Wed, 31 Dec 2008, Thomas Amsler wrote:

> One more question. Now, on the gitweb home page, the project name hyper link
> shows up as:
> 
> authz.git/.git
> 
> where it used to be just:
> 
> authz.git/
> 
> is there a way to configure this so that it doesn't show the trailing .git?

I'm afraid it is not possible without modifying gitweb, unless you use
symlinks in place of real repositories, i.e. if you have authz.git in
$projectroot being symlink to authz.git/.git or even authz/.git (which
might be somewhere else).

For example I have /home/local/scm/git.git be symlink to ~/git/.git

The longer explanation (which probably should made into gitweb/README
or gitweb/INSTALL) is that gitweb is meant to deal with _bare_ 
repositories; gitweb doesn't touch and doesn't examine working area
of "live" (non-bare) repository. If you host git repositories (like
kernel.org, freedesktop.org or repo.or.cz) you usually host them bare
(public repositories should be bare); but you might want to have
gitweb for your own repository too.

-- 
Jakub Narebski
Poland

[PATCH] gitweb: Document that gitweb deals with bare repositories

[Jakub Narebski]

Add reminders to gitweb/README and gitweb/INSTALL that gitweb works
with bare repositories.  While it might be obvious to us, it is not
apparently as evident for newcomers.

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
On Thu, 1 Jan 2009, Jakub Narebski wrote:

> The longer explanation (which probably should made into gitweb/README
> or gitweb/INSTALL) is that gitweb is meant to deal with _bare_ 
> repositories; gitweb doesn't touch and doesn't examine working area
> of "live" (non-bare) repository. If you host git repositories (like
> kernel.org, freedesktop.org or repo.or.cz) you usually host them bare
> (public repositories should be bare); but you might want to have
> gitweb for your own repository too.

And here it is.

By the way, I was wondering if to mark this patch as an RFC, because
I am not completely sure about the wording I used...

 gitweb/INSTALL |   14 ++++++++++++++
 gitweb/README  |   12 +++++++-----
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 18c9ce3..f43e233 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -127,6 +127,20 @@ GITWEB_CONFIG file:
 Gitweb repositories
 -------------------
 
+- Gitweb deals with bare repositories, which means that gitweb scans for
+  (in the case where $projects_list is a directory to search for
+  repositories) or has to be provided with list of (in the case where
+  $projects_list is a text file) bare repositories, i.e. $GIT_DIR for
+  each repository. The consequence of that is the fact that if you use
+  gitweb to view non-bare repository named 'repo' then gitweb would show
+  (or would have to be provided with) 'repo/.git'.
+
+  If you want to view a buch of non-bare repositories in gitweb but want
+  them named 'repo.git' as is the standard for bare repositories, you
+  can as a workaround populare $projectroot / $project_list with
+  symbolic links to $GIT_DIR of each project you want to publish (have
+  shown) in gitweb.
+
 - By default all git repositories under projectroot are visible and
   available to gitweb. The list of projects is generated by default by
   scanning the projectroot directory for git repositories (for object
diff --git a/gitweb/README b/gitweb/README
index 825162a..6dbfcd5 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -34,10 +34,11 @@ You can specify the following configuration variables when building GIT:
  * GITWEB_LIST
    Points to a directory to scan for projects (defaults to project root
    if not set / if empty) or to a file with explicit listing of projects
-   (together with projects' ownership). See "Generating projects list
-   using gitweb" in INSTALL file for gitweb to find out how to generate
-   such file from scan of a directory. [No default, which means use root
-   directory for projects]
+   (together with projects' ownership). Note that gitweb deals with bare
+   repositories; it shows/uses $GIT_DIR for each repository. See also
+   "Generating projects list using gitweb" in INSTALL file for gitweb to
+   find out how to generate such file from scan of a directory. 
+   [No default, which means use root directory for projects]
  * GITWEB_EXPORT_OK
    Show repository only if this file exists (in repository).  Only
    effective if this variable evaluates to true.  [No default / Not set]
@@ -153,7 +154,8 @@ not include variables usually directly set during build):
    Absolute filesystem path which will be prepended to project path;
    the path to repository is $projectroot/$project.  Set to
    $GITWEB_PROJECTROOT during installation.  This variable have to be
-   set correctly for gitweb to find repositories.
+   set correctly for gitweb to find repositories.  (Note that gitweb deals
+   with bare repositories.)
  * $projects_list
    Source of projects list, either directory to scan, or text file
    with list of repositories (in the "<URI-encoded repository path> SP
-- 
1.6.0.4