X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/562e24d695a88b0da851de44952d73568a62712e..a1e106359191de2ef52529e34cfa505e424c0195:/doc/todo/git_attribution/discussion.mdwn?ds=sidebyside diff --git a/doc/todo/git_attribution/discussion.mdwn b/doc/todo/git_attribution/discussion.mdwn index d7796c017..6905d9b4b 100644 --- a/doc/todo/git_attribution/discussion.mdwn +++ b/doc/todo/git_attribution/discussion.mdwn @@ -10,10 +10,13 @@ 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. @@ -42,6 +45,7 @@ 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 <>" [[harningt]] @@ -49,9 +53,46 @@ no determination of uniqueness) > Yes, it does: > -> joey@kodama:~/tmp/foo/bar>git commit --author "foo" -> fatal: malformed --author parameter +> joey@kodama:~/tmp/foo/bar>git commit --author "foo" +> fatal: malformed --author parameter > > It 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 ', +> 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 ", or +> "joey ".