]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/git_attribution/discussion.mdwn
Merge commit 'upstream/master' into prv/po
[git.ikiwiki.info.git] / doc / todo / git_attribution / discussion.mdwn
index 5932e9d42052d066dbdb7a22caa91d8714b60f64..dfb490bc21e18b4f67b7b4b511ddc82d25bd309c 100644 (file)
@@ -4,4 +4,95 @@ I might even have a try at this patch, though I'd have to hack the user preferen
 
 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.
 
-[[harningt]]
\ No newline at end of file
+[[harningt]]
+
+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 <>"
+
+[[harningt]]
+
+[[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 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]]
+>>
+>>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>".