Merge commit 'origin/master'

[git.ikiwiki.info.git] / doc / todo / git_attribution / discussion.mdwn

diff --git a/doc/todo/git_attribution/discussion.mdwn b/doc/todo/git_attribution/discussion.mdwn
index d7796c017c099a6a6b0ce6066bfc3271fe802c87..dfb490bc21e18b4f67b7b4b511ddc82d25bd309c 100644 (file)
--- 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.
 
 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).
 
 
 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.
 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)
 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]]
 
 
 [[harningt]]
 


@@ -49,9 +53,46 @@ no determination of uniqueness)
 
 > Yes, it does:
 > 
 
 > 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 <foo>" -- doesn't seem to
 > do any kind of strict checking. Even "http://joey.kitenet.net <>" will be
 > accepted. --[[Joey]]
 > 
 > It seems to be happy with anything of the form "foo <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>".