git notes are a very important part of git - they're the recommended mechanism for adding additional, after-the-fact metadata to a commit without changing its hash. So for a case like this, they're the only real option. We really need to add support for reading in notes and mapping them to their corresponding commits.

It's gonna be an interesting challenge, since notes are internally very good at chasing around rebased commits - something we haven't had to be diligent about *at all*, even conceptually.

CommentFileSizeAuthor
#13 git-notes-0.patch5.96 KBmarvil07
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

sdboyer’s picture

Issue tags: +vc-next

yup yup.

webchick’s picture

markcarver’s picture

markcarver’s picture

moshe weitzman’s picture

Why does VCS API have to care about Notes? IMO, d.o. could implement a custom module which implements a hook that gets fired for each commit. The hook would extract the Note data and populate issues or or a custom table to store commit credit info.

markcarver’s picture

This is for the VC API (Git backend) project, not the main project. You're correct in that VC API shouldn't care about git notes.

d.o. could implement a custom module which implements a hook that gets fired for each commit.

From my understanding VC API has be extended whenever possible, instead of trying to make d.o even more of a one off. One of the pain points that many have observed from the D7 upgrade of d.o is that there was too many "custom modules" for doing things. This is certainly something that entire VCS API project can benefit from as a whole, not just d.o. We should likely add an event plugin in this module now that #1796144: Add a "event processor" plugin type for repositories is in VC API.

moshe weitzman’s picture

From VC API project page:

42 sites currently report using this module.

I think we might as well accept that VC API is a drupal.org specific code and if anyone else uses it, thats gravy. I bet most of those 42 sites are d.o. clones. So in this context, all of this code is one-off.

FWIW, I think project module suite is in the same boat. We have many years of experience with that and number of sites that have used that and stuck with it is very very low. What we have here are custom solutions, and thats OK.

markcarver’s picture

So.. I'm confused....

#5: Why does VCS API have to care about Notes? IMO, d.o. could implement a custom module which implements a hook that gets fired for each commit.

#7: I think we might as well accept that VC API is a drupal.org specific code and if anyone else uses it, thats gravy.

Is that not what this project is for/has become: "d.o's custom module" (as a separate project for easier management)?

Also, I just want to clarify that this is for the git sub-project of VC API, not the main project.

webchick’s picture

The intention of making things like VCAPI/VCAPI Git full, separate contrib projects was indeed to encourage their use outside of Drupal.org. I think however we can say that this goal has basically failed, given the last year+ of the D.o D7 upgrade was D.o people porting projects like VCAPI, Project, etc., not "the community" (as it was in the case of modules like Views, Entity Reference, etc.)

Basically, I agree with Moshe's assessment of the ecosystem around these tools. He's going a step further and saying is it doesn't matter where the data gets stored: in a proper VCAPI-controlled table or in a totally custom table in drupalorg module; it's still code the D.o team has to ultimately port and maintain.

marvil07’s picture

Let's please skip the "is vcsapi* d.o only?" discussion for now, as webchick mention it does not matter for now since most of the work is currently made by d.o people.

On why IMHO this would benefit to happen in versioncontrol_git: It is definitely the natural place to look for it, therefore improves maintainability and let external new people find it quicker.

Also I do not see why this should happen as event processor plugin, this could be part of general sync process in git backend(which can happen on push or separated).

Naturally the way we interpret git notes content should live either in versioncontrol_project or drupalorg projects depending on how specific it is for d.o

I am not yet convinced git-notes is the right solution for this, see #1583840: Define conventions around drupal core git interaction, but it sounds like we are about to implement this and this is a popular idea, so I guess I could help.

On how to implement it:
git notes are a good hack on git architecture, it is just a new refspace where each ref workspace contains files corresponding to commit hashes containing the text added to as "note".
In this way it reuses git usual object storage and ref history features.
I think that could live on our versioncontrol_operations table, for now vc_git only uses type commit, but we can extend it to have a new "git note" type.
We probably want to do something similar for notes heads in versioncontrol_labels, i.e. a new label type "git note".

marvil07’s picture

marvil07’s picture

It's gonna be an interesting challenge, since notes are internally very good at chasing around rebased commits - something we haven't had to be diligent about *at all*, even conceptually.

I have not yet see how they follow rebased commits, but even if so, because of the way notes are stored, we probably would have integrity anyway, since we will be parsing the updated git-note refs.

marvil07’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Priority: Major » Normal
Status: Active » Needs work
FileSize
5.96 KB

Lots of pending work yet.

BTW not sure why this is marked as major, back to normal.

DamienMcKenna’s picture

Given there were sessions at DrupalCon Dublin that touched on how to give more people credit in an issue commit, should we start pushing on this again?