Co-Author support in arc land
Open, NormalPublic
TitanNano
tobiaswiese
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.
Revisions and Commits
rP Phorge
Needs Review D25028 Co-Author support in arc land T15044
rARC Arcanist
TitanNano created this task.Sep 4 2021, 20:032021-09-04 20:03:26 (UTC+0)
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.
chris added a comment.Sep 4 2021, 21:092021-09-04 21:09:37 (UTC+0)
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... ¯\_(ツ)_/¯
CSharp added a subscriber: CSharp.Sep 4 2021, 22:142021-09-04 22:14:05 (UTC+0)
In T15044#1193, @speck wrote:
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 [...]
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.
TitanNano added a comment.Edited · Sep 4 2021, 22:442021-09-04 22:44:57 (UTC+0)
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.
TitanNano added a project: Arcanist.Sep 5 2021, 21:412021-09-05 21:41:35 (UTC+0)
TitanNano added a revision: D25028: Co-Author support in arc land T15044.Dec 1 2021, 10:552021-12-01 10:55:49 (UTC+0)
TitanNano added a comment.Dec 1 2021, 10:582021-12-01 10:58:15 (UTC+0)
I submitted a draft revision for this. It's not quite complete yet, but anyone interested can take a look at it.
TitanNano triaged this task as Normal priority.Dec 1 2021, 12:582021-12-01 12:58:28 (UTC+0)
TitanNano updated the task description. (Show Details)
avivey added a subscriber: avivey.Dec 18 2021, 07:372021-12-18 07:37:40 (UTC+0)
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.