X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/35f943e6f8d2c7689ea7649053a09aeac9f0c5f3..4e7b7a178890eb8d28edcd2e6ab2763c9a3988e5:/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 21898a1c9..6905d9b4b 100644 --- a/doc/todo/git_attribution/discussion.mdwn +++ b/doc/todo/git_attribution/discussion.mdwn @@ -15,6 +15,8 @@ If no email set, I think "$USERNAME" is reasonable... no point in the 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. @@ -51,8 +53,8 @@ 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 @@ -61,3 +63,36 @@ no determination of uniqueness) >>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 ".