I'd strongly recommend this modification to ikiwiki. Any particular limitations that anyone can think of?
I might even have a try at this patch, though I'd have to hack the user preferences page to include author name...
As to the question of whether the committer was the 'script' or the wiki editor... I'm not sure. Marking it as the script somehow (ikiwiki-cgi <ikiwiki@sitename>)? seems to make sense and would make it easier to manage.
I've been thinking a bit about the GIT attribution in ikiwiki...
If no email set, I think "$USERNAME" is reasonable... no point in the '<>' causing clutter.
adjustement wrt comments: leave the '<>' in due to requirements in git
If no username set... then something like '@[IPADDR]' makes sense... (not in email brackets).
Why not put it in email brackets? --Joey
In the case of OpenID login.. I think that's a special case... I don't think attempting to munge something meaningful out of the OpenID makes sense... but I think some massaging might need to be done.
Ex: I've noticed in the current mode where logging in w/ harningt.eharning.us/ shows up in the logs w/o HTTP and if I login w/ http://harningt.eharning.us/ is shows up w/ the http... causing some inconsistency. I think it oughtta make sure that it has the properly discovered, canonicalized form (ex: if there's a redirect to another site (harningt.eharning.us -> www.eharning.us) then technically the target site is the 'real' openid (at least according to how most OpenID RPs take it).
...
For OpenID edits, I think there should be a way to tell it what username to show in the preferences dialog (so you can have a 'normal' $USER <$EMAIL> setup.) This could by default be filled in w/ sreg nickname value (as well as email for that matter)...
To convey the openid used to make the edit, I think it would be important that some sort of footer line along the lines of the Signed-off: $USER <$EMAIL> conventions I've seen.
Perhaps an OpenID: $OPENID_URL would make sense. This could help w/ making sure that no one irrefutably spoofs a post by someone (since w/ the setup where email and effective username are configurable, there's no determination of uniqueness)
adj re git req: "$OPENID_URL <>"
madduck: git requires Name <Email@address> format, as far as I know.
Yes, it does:
joey@kodama:~/tmp/foo/bar>git commit --author "foo" fatal: malformed --author parameterIt seems to be happy with anything of the form "foo " -- doesn't seem to do any kind of strict checking. Even "http://joey.kitenet.net <>" will be accepted. --Joey
Sounds good to me,
--harningt
I think the thing to do is, as Josh suggested originally, use GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL. Note that setting these individually is best, so git can independently validate/sanitize both (which it does do somewhat). Always put the username/openid/IP in GIT_AUTHOR_NAME; if the user has configured an email address, GIT_AUTHOR_EMAIL can also be set.
There is one thing yet to be solved, and that is how to tell the difference between a web commit by 'Joey Hess <joey\@kitenet.net>', and a git commit by the same. I think we do want to differentiate these, and the best way to do it seems to be to add a line to the end of the commit message. Something like: "\n\nWeb-commit: true"
For backwards compatability, the code that parses the current stuff needs to be left in. But it will need to take care to only parse that if the commit isn't flagged as a web commit! Else web committers could forge commits from others. --Joey
BTW, I decided not to use the user's email address in the commit, because then the email becomes part of project history, and you don't really expect that to happen when you give your email address on signup to a web site.
The problem with leaving the email empty is that it confuses some things that try to parse it, including: * cia (wants a username in there): * git pull --rebase
* github pushes to twitter
So while I tried that way at first, I'm now leaning toward encoding the username in the email address. Like "user <user\@web>", or "joey http://joey.kitenet.net/@web".
