description file
Ralf Hemmecke
I am a bit frustrated. Maybe I haven't studied the gitolite
documentation well enough, but searching through it for the word
"description" is not very effective.
Look at the following:
>git push origin master
Counting objects: 20, done.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 2.01 KiB, done.
Total 14 (delta 10), reused 0 (delta 0)
remote: sed: can't read ./description: No such file or directory
To gitolite:foo
504f9b6..087bc1a master -> master
The date is transmitted perfectly, but I'm somehow bothered by this
"sed" error message. I don't like error messages. ;-)
When I add a description file on the server, it is removed (either by
pushing to the "foo" repo or to the "gitolite-admin" repo --- I haven't
yet checked exactly which one).
Looking at
http://sitaramc.github.com/gitolite/doc/gitolite.conf.html#_repo_owner_description_line_for_gitweb
seems to suggest that gitolite uses the description file to enable gitweb.
I don't run gitweb and don't want to. Still I don't like to see error
messages.
That error message is certainly irrelevant since anything else works
fine, but it is confusing. I would count it as a bug.
My installation method was gl-easy-install.
Um, I don't know whether that is relevant, but on the server I have
enabled the post-receive hook and use
/usr/share/doc/git/contrib/hooks/post-receive-email
to send email with every push. Looking at that script, I can find
projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
which somehow seems to suggest, that this is the reason for the error
message.
Well, now it's possible to argue that the post-receive-email lives under
git/contrib and is therefore not part of the official git, but I rather
find that removing the "description" file from the repo (as done by
gitolite) is somehow conflicting with the standard .git directory contents.
What do you think about it?
Ralf
Sitaram Chamarty
> remote: sed: can't read ./description: No such file or directory
> Well, now it's possible to argue that the post-receive-email lives under
> git/contrib and is therefore not part of the official git, but I rather
> find that removing the "description" file from the repo (as done by
> gitolite) is somehow conflicting with the standard .git directory contents.
Nothing in git documentation suggests that file is
mandatory, so gitolite removes that file when a description
is not supplied.
[Specifically, when you add a description line into the
gitolite conf file for a repo, the file appears. Later, if
you remove it, the file goes away. The way this is done, if
you *never* use descriptions, all of them disappear].
If you look at the code, it is essentially taking the text
"Unnamed repository..." and converting it to "UNNAMED
PROJECT". Clearly, those strings are ad hoc stuff meant for
humans consumption, and any *script* relying on them needs
fixing to be more "strict" in some sense.
So a better fix is for you to use (and send to git.git, if
you can) a patch to the email hook adding a "2> /dev/null"
to that sed command.
regards,
sitaram
Ralf Hemmecke
> mandatory, so gitolite removes that file when a description
> is not supplied.
Well, as I said... that can be one position. I don't argue for one or
the other, the point is only that (if) I cannot change the git
installation on the server, I'm out of luck.
> [Specifically, when you add a description line into the
> gitolite conf file for a repo, the file appears.
Hmmm. Sorry, but the only description of how to do this is this here.
http://sitaramc.github.com/gitolite/doc/gitolite.conf.html#_repo_owner_description_line_for_gitweb
1) This explicitly mentions gitweb. Since I don't want gitweb, I
wouldn't look at it.
2) It does not say that it will create a description _file_.
That would be my criticism for that part of the docs. But now I know.
Incidentally, I've now learned about setting hooks via gitolite.conf.
That's nice! I can even keep that kind of config stuff under revision
control.
> So a better fix is for you to use (and send to git.git, if
> you can) a patch to the email hook adding a "2> /dev/null"
> to that sed command.
Yep, but I hope that the maintainer of post-receive-email is reading the
gitolite list. ;-)
Anyway, gitolite is cool!
Ralf
Sitaram Chamarty
> >Nothing in git documentation suggests that file is
> >mandatory, so gitolite removes that file when a description
> >is not supplied.
>
> Well, as I said... that can be one position. I don't argue for one or
> the other, the point is only that (if) I cannot change the git
> installation on the server, I'm out of luck.
for scripts in contrib/hooks, they're yours to control.
Even if the git installation on the server is managed by
someone else. contrib is just a starting point for local
admins to build on.
> >[Specifically, when you add a description line into the
> >gitolite conf file for a repo, the file appears.
>
> Hmmm. Sorry, but the only description of how to do this is this here.
>
> http://sitaramc.github.com/gitolite/doc/gitolite.conf.html#_repo_owner_description_line_for_gitweb
> 1) This explicitly mentions gitweb. Since I don't want gitweb, I
> wouldn't look at it.
>
> 2) It does not say that it will create a description _file_.
sure. What that link is describing is a high level
behaviour, and what I was describing in the previous email
was the implementation.
> That would be my criticism for that part of the docs. But now I know.
I probably won't add it. I already get too many "tl;dr"
complaints about my docs :(
> Incidentally, I've now learned about setting hooks via gitolite.conf.
> That's nice! I can even keep that kind of config stuff under revision
> control.
>
> >So a better fix is for you to use (and send to git.git, if
> >you can) a patch to the email hook adding a "2> /dev/null"
> >to that sed command.
>
> Yep, but I hope that the maintainer of post-receive-email is reading the
> gitolite list. ;-)
Very unlikely. The smaller project has to send to the
larger project :-)
So as you saw I posted a patch, copying you (but not the
gitolite list, to spare them the traffic).
Actually even that patch is not "correct" in the sense of
what happens when the file doesn't exist -- but it's screwy
to start with, using English text meant for humans in a test
in code -- yuck!. So I didn't want to go overboard on
fixing it.