Hacker News Reader

Comment by bccdee | Hacker News Reader

The workflow the original post is describing is basically a merge request.

As someone who uses Git for technical writing and Word's revision system for fiction that goes back and forth with an editor, I mean, sure, it's sort of a merge request, but you need to place a higher value on the "goes back and forth with an editor" part of the requirement than I think you are. :) An editor suggests changes, sometimes by editing directly and sometimes by leaving comments, that the author can accept, delete, or modify, right? If we're talking about technical writing that's already in a Git repo, then using a PR review system like GitHub's is an acceptable substitute. If we're talking about somebody sending a story to the New Yorker, we're not.

I'm definitely not saying established organizations should change their workflows to "just use git" or something—word processors already offer these features, and the workflow at the New Yorker is already tailored around the affordances of Word documents.

The underlying data model, though—passing around diffs and comments, tweaking sets of modifications before applying them—is the same. You could put together a decent editing workflow around git (although maybe the UI would need to be different from what we use for code). Version control is editing, is my point.

What, and do seperate commits and merges for every comma and dangling modifier? That makes no sense. In addition, there needs to be comments and queries.

Well, no, no more than you would package each comma or dangling modifier into a separate change-tracked .docx. The underlying unit of revision here is a full change set, rather than an individual change.

Reply on news.ycombinator.com