Posted by haxney on June 21, 2009 at 9:51pm
| Project: | Version Control API -- Git backend |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | critical |
| Assigned: | marvil07 |
| Status: | closed (won't fix) |
| Issue tags: | git phase 2, git sprint 5 |
Issue Summary
Right now, the backend uses the full Git username and email to determine whether to attribute a git commit with a Drupal user. Since the username part of the Git commit can vary, it would be more reliable to use only the email address, and include the username only for display purposes.
Comments
#1
In order to assign the uid to an operation, Version Control API looks up if any username in {versioncontrol_accounts} matches the one given in $operation['username']. That means if the latter does not match the stored username, the corresponding Drupal user won't be found. So having the email as unique identifier (username) for the account makes a lot of sense.
#2
This is a 100% must for phase 2 to complete
#3
Seems like this should be kinda moot, since we have the uid in the operations (to-become-commits) table, which represents the final product of mapping efforts. But I need to look at the code. I'm pretty sure when I rewrote the log parser recently, I made it map purely based on email, but I'm not sure. Marking it needs review to make sure it gets handled, though I think we can mark it closed soon.
#4
this will be affected by:
#965890: [meta] Revisit VersioncontrolAccount and bring it up to speed
#898816: Consider using real names and/or e-mail addresses for the author/committer metadata?
#965930: Get the log parser finished. Really.
so.. postponing
#5
Tagging for consideration in git sprint 5
#6
to do at parsing logic
#7
Now that #979040: Make pluggable the process of mapping of raw vcs data to Drupal users gets in, we need to implement this inside a plugin :-)
#8
Here the plugin, it only supports one mail, taken from {users}.mail, so we should create one more plugin if we end up supporting several emails per user(it going to be dependent on the solution to provide several mails).
#9
#10
The simple mail plugin that's already written should be perfectly adequate, because it's a mistake to smoosh that data in place. The plan for changing how we do that is here: #988512: Properly track git's user.email and user.name as separate, first-class properties
Won't fixing this.
#11
I see the point in the related issue, so let's do it there.
BTW #988512: Properly track git's user.email and user.name as separate, first-class properties was created after I created the patch, so making public that kind of decisions early could avoid wasting efforts for the next time ;-)