When landing a range of commits with arc land and the squash strategy, the resulting commit should contain all co-authors.
The co-authors would preferably be determined based on all commits of the revision which have not been authored by the author of the revision. If any of the commits contains co-author information, that should be included as well.
Functionally I think this makes sense, though from a higher perspective the concept of "multiple authors on a revision" might need to be discussed and fleshed out.
Technically this workflow can be supported today as arcanist will allow you to make updates to a diff that was originated/authored by someone else however in my experience this tends to be fraught with issues, largely related to multiple contributors forgetting to update their local repositories with updates that were made by others resulting in lots of conflicts and having to pick apart changes.
@TitanNano additional context around the development style that causes this issue to come up would be useful to include here.
Ref also Git Commit Message Conventions. Adding a Co-authored-by: name <name@example.com> trailer to the commit message seems fairly well-accepted, at least for Git. GitHub and GitLab both recognize and parse it when present.
Whether or not it's a good thing to do... ¯\_(ツ)_/¯
I've come across this or a very similar "issue" when working with the Live share extension for VS Code. VS Code will add the line to any commits that originate during the session, but they will get lost when arc squashes the commit. I've never had issues with the commits themselves since I would agree that working on the same diff on different computers is a PITA.
We are a small team, and sometimes one engineer has to take over a revision originally authored by someone else.
This can happen due to sick leave or time off, and stuff has to get done. There have also been situations where an engineer was already going through several iterations with his revision and someone more experienced had to go in and set things right, so we could meet our deadlines. We don't like it, but sometimes we can't avoid it. It's not completely necessary to track all people involved in a revision, since it's really authored by one person for the most part, but would be nice if such information could be preserved.
I submitted a draft revision for this. It's not quite complete yet, but anyone interested can take a look at it.
I've left a comment on the server-side diff.
This is the kind of changes I'd like to be in a custom extension rather then in the core. That doesn't mean it can't go in core - it just needs to decoupled in such a way that the co-author specific stuff could have been an extension, to be a reference implementation for other similar fields.
If this means making changes in the core, that's great, as long as these changes are generic to improve extensibility.
Roughly, this means to reduce special cases in the code (DifferentialGetCommitMessageConduitAPIMethod and ArcanistGitAPI), and add generic capabilities to the core to allow this feature as needed.