Suggestion for method to include individual contributions.

[ryao]

We may not be able to reflect individual contributions as separate git commits in the GitHub repository.

This is likely easier than you realize. When syncing the repository to a new driver version, first cherry pick the contributor commits. Then replace all of the files with what they would have been following the mega patch to update it to the latest Nvidia driver version and commit the changes. The result is that you will have the git history reflect individual contributions, without much effort.

The only downside is that git bisect might not always work if the individual patches somehow break things in a way that is fixed in the mega patch, but that could be caught by a buildbot and quite frankly, I suspect the community would prefer that the commit history reflect individual contributions over a guarantee of being able to use git bisect.

[aaronp24]

It's not quite that simple because we have multiple branches internally and we have to evaluate contributions to determine which branch they need to be applied to (e.g. fixes will go into 515, enhancements and cleanups will go into the mainline). In the future we may end up with releases from multiple branches in flight.

[ryao]

It's not quite that simple because we have multiple branches internally and we have to evaluate contributions to determine which branch they need to be applied to (e.g. fixes will go into 515, enhancements and cleanups will go into the mainline). In the future we may end up with releases from multiple branches in flight.

There is nothing preventing this from being done even with multiple branches, although it would require a bit of book keeping to keep track of what needs to be cherry-picked for what branch. You could keep an internal document listing what has been added to each branch, for use when the code drop to the open source repository is done. If it is added to multiple parallel branches, just list it in each for cherry-picking prior to the code drop.

[hramrach]

Why does it have to be code drops and the development history cannot be published?

[hramrach]

Not the history since the dawn of time but the history between the public releases.

[mtijanic]

We appreciate suggestions on how to improve the workflow and will take them under advisement. But please keep in mind that there are significant obstacles to the traditional ways of dealing with the issues, such as (but not limited to):

• Code internally at NVIDIA lives in a Perforce monorepo and not git.
  • Moreso, the Perforce workflow is customized to work with our internal tooling
• Parts of the code in question are shared with various other components, such as microcode or Windows driver
• The internal directory structure does not match the structure of the published driver
• Some code exists in multiple copies (e.g. Windows vs Linux impl), but only one is published
  • Alternatively, different major releases (e.g. 515.xx vs 510.xx) live concurrently but can have significant code divergence.

All of the above makes it prohibitively difficult to do anything other than a clean slate code drops for the time being.

If I'm understanding @ryao 's suggestion, it is not much different than what we do currently:

• Initial code drop submitted to GitHub
• Merge PRs from community into main. Merge same PRs into Perforce internally
• Next release, overwrite entire repo with the next code drop
• Hope that git bisect/blame/etc recognize the changes across these releases.

However, there may be cases in which a community PR makes sense for this repo, but does not make sense in the internal codebase (in ways we can't expect the author to know about). Or cases where the PR is high risk and we might want a multi-month QA run with it internally before merging (possibly modified). In these cases it might be costly to reflect the contributions in the commit log and still see a coherent history.

[hramrach]

The general idea is that if you have a tool that can convert a release commit into a code drop you can also convert the commits in between release commits, and the commits down to a common ancestor of the currently active branches. That way you can create a copy of a subset of the internal history in the public repository that generally makes sense in the context of the published code.

However, if such tool does not exist and each code drop is hand-crafted this is not feasible, and even if it does it may not be practical. Can't really say without knowing what the internal repository looks like and what tooling is available.

[MilesBHuff]

I see a rather simple solution, here: Just do your usual thing internally, and then when it comes time to publish that to GitHub, make a single huge commit containing all the changes, and then push that up -- no need to wipe the history of the git repo.

[ryao]

I see a rather simple solution, here: Just do your usual thing internally, and then when it comes time to publish that to GitHub, make a single huge commit containing all the changes, and then push that up -- no need to wipe the history of the git repo.

Doing this would mean the only history in the git repository would be mega-commits from code drops.

[MilesBHuff]

Doing this would mean the only history in the git repository would be mega-commits from code drops.

That's not true; the history would remain unless there's a rebase or force-push. The exact same git repo would be used -- new code drops would just be committed on-top of what's already there.

[maxwellb]

I see a rather simple solution, here: Just do your usual thing internally, and then when it comes time to publish that to GitHub, make a single huge commit containing all the changes, and then push that up -- no need to wipe the history of the git repo.

Doing this would mean the only history in the git repository would be mega-commits from code drops.

As a community member, I would be okay with this given their internal workflow challenges (thank you). That is, provided that some other record of attribution be maintained. I've definitely seen other projects attribute contributors in CHANGES with a dump of commit summaries and issue tracking numbers. If it's important to maintain "diff view" perhaps Nvidia could upload patch files which reflect the actual merge performed. Though to me, there is a lot of valid history in GitHub issues that supplements what is in the repo itself.