Force specific usernames for Mercurial commits

mercurialuser-accounts

We're switching from Subversion to Mercurial in our corporate environment. There will be a central repository that is accessible via HTTPS with basic HTTP authentication.

Now I'm curious whether it's possible to force specific usernames for commits? I'm talking about the usernames that can be set in .hgrc like this

[ui]
username = John Doe <john.doe@mycompany.com>

and that are visible in the log messages.

Because this file is placed on each developer's machine it's outside of the administrator's control.

This wouldn't be a problem because we trust our internal developers but externals (freelancers) will also have access to at least some repositories. We definitively don't want them to checkin under different names.

It would be great if the username can be bound/forced to the HTTP username. For example if John pushes his changes to the URL https://john@mycompany.com/hg/project1 then the usernames of all commits will be set to John Doe <john.doe@mycompany.com.

Is this possible?

Best Answer

You can enforce the usernames at the server side, at push time. I.e. for your freelancers it might be feasible to only let them push changes that contain some pre-approved username (this can somewhat restrict other nice features of Mercurial, i.e. that people can share their changes with each other before pushing). You might also just have a complete list of pre-approved usernames on the central server.

All this can be done with a pretxnchangegroup hook.

Related Solutions

Git and Mercurial

Some time back google did an analysis of Git and Mercurial. You can read it online on

~~http://code.google.com/p/support/wiki/DVCSAnalysis~~

(according to a comment this may be related to the above dead link; since comments are volatile, I am editing it into the answer)

Nginx – Mercurial not receiving push

I spent ages trying to get hgwebdir working with nginx and it is a bit of a hassle, because hgwebdir won't send the request to the browser for authentication. In the end I solved it like this:

server {
        listen 80;
        listen 10240;
        server_name code.zofrex.com;
        access_log /home/zofrex/websites/code.zofrex.com/logs/access.log;
        error_log /home/zofrex/websites/code.zofrex.com/logs/errors.log;

        location / {
                limit_except GET {
                        proxy_pass http://localhost:81;
                }
                fastcgi_pass 127.0.0.1:10001;
                include fastcgi_params;
        }

        location ~ ^/(HGBot|ZeroBotAHD|zoebot|FZeroZBot|RDPrototype|RSPS3000|zerobot|rmi)  {
                proxy_pass http://localhost:81;
        }

        include defaults;
}

server {
        listen 81;

        access_log /home/zofrex/websites/code.zofrex.com/logs/access_secure.log;
        error_log /home/zofrex/websites/code.zofrex.com/logs/errors_secure.log;

        location / {
                auth_basic           "Restricted";
                auth_basic_user_file /home/zofrex/passwords;
                fastcgi_pass 127.0.0.1:10001;
                include fastcgi_params;
        }

        include defaults;
}

This is the only way you can do it, really, as limit_except can't be combined with fastcgi_pass - in fact no conditionals can, but they be combined with proxy_pass. No idea why.

So how does this work? If a GET request comes in, it's handed off to hgwebdir straight away. If a POST (i.e. a push) comes in, the request upstreams to the proxy on port 81 which always prompts for basic auth, thus ensuring it happens.

Why the location with the huge regex? Those are protected projects that I want to require auth for even read access.

Why the listening on port 10240? I can't remember why that's there.

Oh, and I'm using wsgi with spawn-fcgi, which is why it's fastcgi_pass. This exact config probably won't be right for you but hopefully the same trick will solve your pushing woes.

Related Topic