>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #782408. --> Reported by: [sdboyer](https://www.drupal.org/user/146719) >>> <p>As we've talked about quite a bit in the past couple months, git is internally capable of giving contribution credit where its due. Necessarily, however, that is going to change the way we think about commit statistics. And that's after the count changes resulting from commit atomicity...but let me explain that first to ensure everyone reading this is on the same page with that.</p> <p>Right now, a 'commit' on the d.o CVS system corresponds to a change in a single file, not an actual commit action. So if you make changes to 20 files and then commit all those changes at once, it will actually show up as 20 commits on the project/your user listing. This is because CVS commits are non-atomic. Since git commits are atomic (along with basically every other vcs), there's going to be a change that drastically reduces the number of commits everyone on d.o has, simply because we're counting atomic commits instead of number of files changed. So that's the first change.</p> <p>With the capacity to track contributor commits, though, there's more thinking to do. If we want to give any recognition to contributor participation (which I do), then I think the best approach is to start delineating between 'contributor commits' and 'maintainer commits'. Respectively, those would be commits performed by contributors to an issue repo and later merged into a project repo (but only counted once that merge occurs), versus commits done by the maintainer her/himself. We might even want to split maintainer commits further, to delineate between issue merges and direct author work. Starts getting complicated, I know, but the data's there, and it's at least worth having a conversation about.</p> <p>The decision we make on this front also has to dovetail with the decision we make on the recommended process for maintainers merging in work done in issue repos. On that front, we have two competing goals:</p> <ol> <li>Allow contributors to really duke it out in an issue, making commits all over the place without worrying about anything except getting to the right code</li> <li>Allow mainline/project branches to preserve clean histories</li> </ol> <p>Ordinarily this is easy enough to resolve: either it's the responsibility of the contributor to create a clean, outward-facing branch to pull from (basically the kernel model) or it's the responsibility of the maintainer to pull in and do that maintenance. I think the latter is probably more appropriate for our case; as long as the contributor(s) ensure the merge is clean &amp; good, all the maintainer has to do is a squash merge/rebase. That presents us with a problem, though: squashing is not a history-friendly act, as it doesn't actually pull the commit objects over, only the final state of the content. This is unfortunate, because it means we don't have the actual commits made by the contributors, so we can't count them (also because those commit objects won't actually exist in the project repo, future merges that incorporate only some of those changes might get...a little complicated). This is somewhat overcome-able because squash merges default to populating their commit message with all the commits that are being squashed, so we could parse that for commits to be credited. But in the interest of keeping the project branches clean, we'd either probably need to require squash merges, or require the #nid (+branch name?) in the commit message to trigger proper crediting.</p> <p>This technically doesn't need to be fully resolved until phase 3, but I'm marking it phase 2 because I think the decision may bear on our thinking even during the initial conversion. 'cuz it's definitely bearing on mine.</p>