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

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.

Your actually barking up two separate trees / issues here.

Timur Tabi wrote:

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.

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.

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:

Does this explanation help?

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

Jakub Narebski wrote:

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.

On Fri, 15 May 2009, Timur Tabi wrote:

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.

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.

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

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

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

Timur Tabi <timur@freescale.com> writes:

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.

On Sat, 16 May 2009, Timur Tabi wrote:

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.

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.