doc/todo/git_attribution/discussion.mdwn

   1 I'd strongly recommend this modification to ikiwiki.  Any particular limitations that anyone can think of?
   2
   3 I might even have a try at this patch, though I'd have to hack the user preferences page to include author name...
   4
   5 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.
   6
   7 [[harningt]]
   8
   9 I've been thinking a bit about the GIT attribution in ikiwiki...
  10
  11 If no email set, I think "$USERNAME" is reasonable... no point in the
  12 '<>' causing clutter.
  13 >> **adjustement wrt comments**: leave the '<>' in due to requirements in git
  14
  15 If no username set... then something like '@[IPADDR]' makes sense...
  16 (not in email brackets).
  17
  18 > Why not put it in email brackets? --[[Joey]]
  19
  20 In the case of OpenID login.. I think that's a special case...  I don't
  21 think attempting to munge something meaningful out of the OpenID makes
  22 sense... but I think some massaging might need to be done.
  23
  24 Ex:  I've noticed in the current mode where logging in w/
  25 harningt.eharning.us/ shows up in the logs w/o HTTP and if I login w/
  26 http://harningt.eharning.us/ is shows up w/ the http... causing some
  27 inconsistency.  I think it oughtta make sure that it has the properly
  28 discovered, canonicalized form (ex:  if there's a redirect to another
  29 site  (harningt.eharning.us -> www.eharning.us) then technically the
  30 target site is the 'real' openid (at least according to how most OpenID
  31 RPs take it).
  32
  33 ...
  34
  35 For OpenID edits, I think there should be a way to tell it what
  36 username to show in the preferences dialog (so you can have a 'normal'
  37 $USER <$EMAIL> setup.)  This could by default be filled in w/ sreg
  38 nickname value (as well as email for that matter)...
  39
  40 To convey the openid used to make the edit, I think it would be
  41 important that some sort of footer line along the lines of the
  42 Signed-off: $USER <$EMAIL> conventions I've seen.
  43
  44 Perhaps an OpenID: $OPENID_URL would make sense.  This could help w/
  45 making sure that no one irrefutably spoofs a post by someone (since w/
  46 the setup where email and effective username are configurable, there's
  47 no determination of uniqueness)
  48 >> **adj re git req**: "$OPENID_URL <>"
  49
  50 [[harningt]]
  51
  52 [[madduck]]: git requires `Name <Email@address>` format, as far as I know.
  53
  54 > Yes, it does:
  55 >
  56 >     joey@kodama:~/tmp/foo/bar>git commit --author "foo"
  57 >     fatal: malformed --author parameter
  58 >
  59 > It seems to be happy with anything of the form "foo <foo>" -- doesn't seem to
  60 > do any kind of strict checking. Even "http://joey.kitenet.net <>" will be
  61 > accepted. --[[Joey]]
  62 >>
  63 >>Sounds good to me,
  64 >>
  65 >> --[[harningt]]
  66
  67 > I think the thing to do is, as Josh suggested originally, use
  68 > GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL. Note that setting these
  69 > individually is best, so git can independently validate/sanitize both
  70 > (which it does do somewhat). Always put the username/openid/IP in
  71 > GIT_AUTHOR_NAME; if the user has configured an email address,
  72 > GIT_AUTHOR_EMAIL can also be set.
  73 >
  74 > There is one thing yet to be solved, and that is how to tell the
  75 > difference between a web commit by 'Joey Hess <joey@kitenet.net>',
  76 > and a git commit by the same. I think we do want to differentiate these,
  77 > and the best way to do it seems to be to add a line to the end of the
  78 > commit message. Something like: "\n\nWeb-commit: true"
  79 >
  80 > For backwards compatability, the code that parses the current stuff needs
  81 > to be left in. But it will need to take care to only parse that if the
  82 > commit isn't flagged as a web commit! Else web committers could forge
  83 > commits from others. --[[Joey]]
  84 >
  85 > BTW, I decided not to use the user's email address in the commit, because
  86 > then the email becomes part of project history, and you don't really
  87 > expect that to happen when you give your email address on signup to a web
  88 > site.
  89 >
  90 > The problem with leaving the email empty is that it confuses some things
  91 > that try to parse it, including:
  92 > * cia (wants a username in there):
  93 > * git pull --rebase (?)
  94 > * github pushes to twitter ;-)
  95 >
  96 > So while I tried that way at first, I'm now leaning toward encoding the
  97 > username in the email address. Like "user <user@web>", or
  98 > "joey <http://joey.kitenet.net/@web>".