A draft agreement often goes through internal revisions and edits before it's packaged up as a single "redline" (akin to a diff) that's presented as a package to the other side. The order and scope not only of edits presented, but other alternatives drafted and dropped, or drafted and tweaked, is potentially revealing, as is the timing of edits and the fact of who made them. A live editing environment doesn't let you hide these details when necessary. It also fails to prevent the other side mucking about in the draft as you're reading, reviewing, or editing it. Sometimes everyone will play nice and wait their turns to use the pen, but often they won't.
Similar concerns make it difficult to adapt Git for use with opposing parties, since many of Git's features flow from the way it addresses its tamper-evidence design goal. The only notion of a commit with two ancestors in Git is a merge commit, which nonetheless preserves the complete history of both parents. So one side can't manage internal revisions with in-house commits (bearing author name, timing, exact content, etc.) and then issue a PR, while keeping the history of internal revisions secret. They have to edit history and make a squashed commit available for pull. At that point the incremental benefit of Git is just SSH or HTTP instead of e-mail. It's just managed patchfiles.
Squash commits it does, but I don't think we really want squashed commits.
Squashing works to hide edit history from the opposing side, but it also pulls history out of your own history. You can create a branch at your local head before squashing to save those commits, but when you get an edit back, its new commit will reference your squashed commit. If you rebase onto the branch with your local changes, you can reconstruct "your history", but you'll have to be careful not to push commits from that branch to opposing next round, since it now contains your private edit history again.
Comments
A draft agreement often goes through internal revisions and edits before it's packaged up as a single "redline" (akin to a diff) that's presented as a package to the other side. The order and scope not only of edits presented, but other alternatives drafted and dropped, or drafted and tweaked, is potentially revealing, as is the timing of edits and the fact of who made them. A live editing environment doesn't let you hide these details when necessary. It also fails to prevent the other side mucking about in the draft as you're reading, reviewing, or editing it. Sometimes everyone will play nice and wait their turns to use the pen, but often they won't.
Similar concerns make it difficult to adapt Git for use with opposing parties, since many of Git's features flow from the way it addresses its tamper-evidence design goal. The only notion of a commit with two ancestors in Git is a merge commit, which nonetheless preserves the complete history of both parents. So one side can't manage internal revisions with in-house commits (bearing author name, timing, exact content, etc.) and then issue a PR, while keeping the history of internal revisions secret. They have to edit history and make a squashed commit available for pull. At that point the incremental benefit of Git is just SSH or HTTP instead of e-mail. It's just managed patchfiles.
Forgive my ignorance (I've mostly used svn before) but doesn't rebasing result in squashed commits in the way you'd want?
Squash commits it does, but I don't think we really want squashed commits.
Squashing works to hide edit history from the opposing side, but it also pulls history out of your own history. You can create a branch at your local head before squashing to save those commits, but when you get an edit back, its new commit will reference your squashed commit. If you rebase onto the branch with your local changes, you can reconstruct "your history", but you'll have to be careful not to push commits from that branch to opposing next round, since it now contains your private edit history again.