@bnoordhuis but they make rebasing easier... 😞

Why? You can just git cherry-pick the commits after an update.

Makes it more error prone. Are those commits "sterile"?
I kinda liked this approach and the statement it makes, vendor in GYP as-is and in parallel version track our patches...

I don't know what you mean by 'sterile.' I also don't understand why you think it's more error prone. Can you elaborate?

@bnoordhuis "Sterile" as in including only patches tn GYP code, and are they clearly marked.
Error prone, as in "less obvious to find needed steps" and "easier to miss one".

Assuming the procedure for a GYP update now is:

1. Copy all GYP code (except tests)
2. Apply patches
3. Maybe fix some conflicts, and update .patch files
4. Commit

New process will be:

1. Same as above
2. Find all relevant commits that patch GYP. Which are relevant? maybe some are stale? what's the cut off date? Since last GYP Update?
3. Cherry pick those. Making sure not to miss any.
4. Maybe resolving conflicts.
5. Commit.

Both obviously works, IMHO 2nd one more fragile.

I don't think it's all that different. git log gyp/ shows what patches we float and we have to review them after an upgrade anyway. It's the same process we use in nodejs/node for V8.

All of this may be academic though because upstream gyp is clearly in maintenance mode. I don't expect any big updates before upstream abandons it completely.

Cool 👍