Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Right now, we jam the human-readable output of git log into {versioncontrol_operations}.author and {versioncontrol_operations}.committer. That is, everything after 'Author' shows up in there:
commit ec9b81e4773cd6f5debcbaa2d8ce0c2d31d4fcf9
Author: Sam Boyer <drupal@samboyer.org>
Date: Thu Dec 2 17:40:47 2010 -0800
Internally, git tracks these bits of data separately, and we should do. It means adding a {versioncontrol_git_operations} table, which we're gonna need for other stuff anyway, adding some properties to VersioncontrolGitOperation to contain that data, and modifying the entity controller to properly join the additional table and add the extra fields. This'll also have implications for how we handle views integration (see #970244: Create a views handler to map operation author/committer to their drupal user), but renders #498086: Implement a user_mapping_method that only use only the email address moot.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 988512-more-git-properties.patch | 8.8 KB | sdboyer |
Comments
Comment #1
sdboyer commentedOh, and updates to the log parser, of course, so that we properly tease out the separate bits of data and attach them to the VersioncontrolGitOperation objects.
Comment #2
sdboyer commentedPatch is attached. While I was at it, I also included a field to track parent commit (the SHA, not the vc_op_id), and a field to indicate whether or not it's a merge commit. That field is mostly in anticipation of adding another table which can track all merge heads, then modifying the loader so that it does an extra query to load that data if it's present.
It's tested and works with the latest version of the log parser. The new controller retrieves the data properly, too. Gotta say I'm excited at just how LITTLE additional code was required to extend the datastructures - yay, good architecture! :)
Comment #3
sdboyer commentedComment #4
marvil07 commentedThis looks fine, good architecture FTW!
The only collateral change to do is at backend views overwrite(IIRC we talked about adding a point of interaction at views creation at main VCS API, but can not find an issue for it) to actually change the views, unless we do not really want to change the view, and just stay with the emails(IIRC we do not want that).
Comment #5
sdboyer commentedGood, glad you're on board with this.
Yeah, the views need to be updated to accommodate this. It was this issue that prompted me to comment that I really need to revisit the whole views-extending architecture during sprint 6, because it's felt awkward every time we've done it and it really needs to get solved well.
I think this can probably safely be committed even before that gets changed, though...? Yes, they're related issues, but I don't want to hold up one for the other.
Comment #6
marvil07 commentedThen, let's get this in.
BTW I open an issue about views at #990644: Improve backend interaction with views.
Comment #7
sdboyer commentedGreat, committed. And thanks for opening the other issue.