Newly created repositories get wrong description

124 views
Skip to first unread message

Ralf Jung

unread,
Nov 11, 2014, 5:14:27 AM11/11/14
to gito...@googlegroups.com
Hi,

I am having a small problem with repositories created via gitolite, and
the descriptions shown by gitweb.

Steps to reproduce:
* Add a new repo, e.g. as follows
> repo reponame
> owner = "Ralf Jung"
> desc = "Some Description"
> R = daemon
> RW = ralf
* commit and push
* Go to the gitweb site, and observe reponame's description

Actual behavior:
The description reads "Unnamed repository; edit this file 'description'
to name the repository."

Expected behavior:
I expected "Some Description"

Additional information:
The problem is caused by a file called "description" that exists in the
repository folder in ~git/repositories/reponame. It contains the
actually shown description. After removing that file, the expected
description is shown.

I am using gitolite 3.6.2, git + gitweb 1.9.1 on Debian stable.

Kind regards
Ralf


Sitaram Chamarty

unread,
Nov 11, 2014, 5:31:29 AM11/11/14
to Ralf Jung, gito...@googlegroups.com
Try it with a brand new repo; it should work.

If it doesn't work, we need to dig/debug.

If it does work, I would suggest a one-time, manual, removal of such
description files, because any new repos created won't have this issue.

Here's some background:

In v2, gitolite used to update the 'description' file, but in v3 it does
it using the 'gitweb.description' config value. This is a lot simpler
to maintain, and allows you to also set up 'owner' the same way (i.e.,
the 'gitweb.owner' config value).

However, it turned out that gitweb prefers that file if it is present,
so gitolite takes care to delete it... but only when it is creatig a
brand new repo. (At other times it leaves it alone, since you may have
manually created it and gitolite does not want to be that intrusive).

I suspect the repos you're looking at were either pulled into gitolite
from elsewhere, so gitolite did not "create" it.

HTH

Sitaram Chamarty

unread,
Nov 11, 2014, 5:37:22 AM11/11/14
to Ralf Jung, gito...@googlegroups.com
On 11/11/2014 04:01 PM, Sitaram Chamarty wrote:

Aaaargh; my apologies. You already said "newly created repos".

This means we need to investigate, since I cannot reproduce this.

What do these commands return:

gitolite query-rc GL_BINDIR
gitolite query-rc POST_COMPILE

regards
sitaram

Ralf Jung

unread,
Nov 11, 2014, 9:30:26 AM11/11/14
to gito...@googlegroups.com
Hi,

> Aaaargh; my apologies. You already said "newly created repos".

I did :)
When I first noticed the issue, I noticed these files and deleted them.
But today I created a new repo and the file was created. Maybe git does
that, I don't know.

> This means we need to investigate, since I cannot reproduce this.
>
> What do these commands return:
>
> gitolite query-rc GL_BINDIR
> gitolite query-rc POST_COMPILE

$ gitolite query-rc GL_BINDIR
/home/git/gitolite/src
$ gitolite query-rc POST_COMPILE
post-compile/ssh-authkeys
post-compile/update-git-configs
post-compile/update-git-daemon-access-list
repo-specific-hooks

Kind regards
Ralf

Sitaram Chamarty

unread,
Nov 11, 2014, 10:09:48 AM11/11/14
to Ralf Jung, gito...@googlegroups.com
On 11/11/2014 08:00 PM, Ralf Jung wrote:

> $ gitolite query-rc POST_COMPILE
> post-compile/ssh-authkeys
> post-compile/update-git-configs
> post-compile/update-git-daemon-access-list
> repo-specific-hooks

enable 'gitweb' in the rc file. That should fix it.

(You're missing post-compile/update-gitweb-access-list in there).

Ralf Jung

unread,
Nov 11, 2014, 1:53:11 PM11/11/14
to Sitaram Chamarty, gito...@googlegroups.com
Hi,

>> $ gitolite query-rc POST_COMPILE
>> post-compile/ssh-authkeys
>> post-compile/update-git-configs
>> post-compile/update-git-daemon-access-list
>> repo-specific-hooks
>
> enable 'gitweb' in the rc file. That should fix it.
>
> (You're missing post-compile/update-gitweb-access-list in there).

That did it :)
When I looked at the rc file, I remember that I had commented this out
because it said that this "creates projects.list file". I am not using
that file, instead I told gitweb to display all repositories that
git-daemon can read (by checking for git-daemon-export-ok). I didn't
know that this does more than just creating that file ;-)

Thanks a lot!

Kind regards
Ralf

Sami Hartikainen

unread,
Jun 1, 2022, 9:25:14 AM6/1/22
to gitolite
It looks like this is broken in v3.6.12 ...? When creating new repos, the description file does not get removed.

Snippet from the log:

2022-06-01.16:02:39     381461          system,git init --bare >&2
2022-06-01.16:02:39     381461          system,/opt/gitolite/src/triggers/set-default-roles,POST_CREATE,testing/create_test4
2022-06-01.16:02:39     381461          system,gitolite compile-template-data
2022-06-01.16:02:39     381461          system,/opt/gitolite/src/commands/compile-template-data
2022-06-01.16:02:40     381461          system,gitolite trigger POST_COMPILE
2022-06-01.16:02:40     381461          system,/opt/gitolite/src/triggers/post-compile/ssh-authkeys,POST_COMPILE
2022-06-01.16:02:40     381461          system,/opt/gitolite/src/triggers/post-compile/update-git-configs,POST_COMPILE
2022-06-01.16:02:43     381461          system,/opt/gitolite/src/triggers/post-compile/update-gitweb-access-list,POST_COMPILE

The update-gitweb-access-list is called with POST_COMPILE, never with POST_CREATE as it expects.

My rc file is the same as it was with an earlier Gitolite version (v3.6.5) that worked okay in this respect.

Br, Sami

Sitaram Chamarty

unread,
Jun 3, 2022, 11:36:48 AM6/3/22
to Sami Hartikainen, gitolite
On Wed, Jun 01, 2022 at 06:25:14AM -0700, Sami Hartikainen wrote:
> It looks like this is broken in v3.6.12 ...? When creating new repos, the
> description file does not get removed.

Indeed it is, it looks like it broke at [1]; thanks for catching
it!

[1]: https://github.com/sitaramc/gitolite/commit/cf423a6a74b398eaa1dd67966ab2e02ff422274a

I may have painted myself into a corner there, and I'll need
time to dig through this and figure out the simplest way to deal
with it.

Meanwhile, if it is urgent, a work-around is to create a new
PRE_CREATE trigger that just does that.

But honestly I'm toying with the idea that I should blindly
remove the file right after the `git init` happens; can't hurt
anything.

Please let me know if it is urgent, because I am (after a long
gap!) traveling this weekend and may not have time till the
next.

Thank you again for catching the bug!

regards
sitaram
> --
> You received this message because you are subscribed to the Google Groups "gitolite" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to gitolite+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/09f18a11-a560-4fc3-8dab-4d8771c898e2n%40googlegroups.com.

Sami Hartikainen

unread,
Jun 4, 2022, 7:39:35 AM6/4/22
to gitolite
Not an urgent matter, have a good weekend!

We had only a handful of new repos created which were affected; fixed them with some one-time scripting.

Br, Sami

Sitaram Chamarty

unread,
May 22, 2023, 9:40:37 PM5/22/23
to Sami Hartikainen, gitolite, bre...@unb.ca
On Sat, Jun 04, 2022 at 04:39:35AM -0700, Sami Hartikainen wrote:
> Not an urgent matter, have a good weekend!

I had a good *year* it seems :)

David Bremner ran into the same problem a few days ago and
reminded me on IRC. Sorry for missing this. (I'll probably go
through all my gitolite emails soon, in case there are other
issues I have similarly missed!)

> We had only a handful of new repos created which were affected; fixed them
> with some one-time scripting.
>
> Br, Sami
>
> On Friday, June 3, 2022 at 6:36:48 PM UTC+3 sita...@gmail.com wrote:
>
> > On Wed, Jun 01, 2022 at 06:25:14AM -0700, Sami Hartikainen wrote:
> > > It looks like this is broken in v3.6.12 ...? When creating new repos,
> > the
> > > description file does not get removed.
> >
> > Indeed it is, it looks like it broke at [1]; thanks for catching
> > it!
> >
> > [1]:
> > https://github.com/sitaramc/gitolite/commit/cf423a6a74b398eaa1dd67966ab2e02ff422274a
> >
> > I may have painted myself into a corner there, and I'll need
> > time to dig through this and figure out the simplest way to deal
> > with it.
> >
> > Meanwhile, if it is urgent, a work-around is to create a new
> > PRE_CREATE trigger that just does that.
> >
> > But honestly I'm toying with the idea that I should blindly
> > remove the file right after the `git init` happens; can't hurt
> > anything.

I took a good long look at the code as it stands right now, and,
short of undoing some important, efficiency related, changes,
this *is* indeed the best way to deal with this.

What I ask is if some of you can apply this simple patch
(attached) and see if you find something I missed (though TBH
it's a very trivial patch so I don't expect anything).

thanks, and sorry again for the delay!

sitaram
> To view this discussion on the web visit https://groups.google.com/d/msgid/gitolite/ab6e65ae-c598-4dc2-8e1e-326fe8a1ddf2n%40googlegroups.com.

remove-default-created-description-file.patch
Reply all
Reply to author
Forward
0 new messages