3 ms·

Have you not ever found any value in `git bisect`? If you have a bug which is reproducible, but whose cause is complex, do you not think it's useful to be able

Have you not ever found any value in `git bisect`? If you have a bug which is reproducible, but whose cause is complex, do you not think it's useful to be able to find the commit that introduced the bug in order to see which change caused it? If only to get a good first idea of what might need to be fixed? Currently, `git bisect` works best if every commit is buildable and runnable, in order that any commit can be automatically tested for the presence of the bug, to narrow down the problem commit as quickly as possible. If some commits don't build or run because they contain conflict markers, this make `git bisect` need a lot more manual intervention. Can you think of a way in which an equivalent of `git bisect` might be adapted to work in this scenario? Note that just scanning for conflict markers might not be appropriate, in case a file legitimately contains text equivalent to conflict markers - e.g. in documentation talking about conflict markers, or something like `=======` being usable as an underline in some markup languages.

josephg 3y ago
Yeah git bisect is great. And CRDTs on their own probably won’t preserve enough information to allow bisecting to happen - since we don’t know which points in time have working builds. One approach to preserve the ability to bisect would be to allow users to periodically mark points in time with “commits” if they want. The commits wouldn’t be used for synchronisation or merging (since we have the crdt information for that). Instead, they could act semantically much more like anonymous git tags. But they would still be useful as landmarks to mark working builds and milestones. And for git bisect. We could give them associated commit logs. (“Got feature X working”, “Release 1.0.5”, etc). Commits might also be a good way to manage pruning. If users type then delete something, many CRDTs will keep a copy of the deleted characters indefinitely in a log. But we could design it so it only durably persists inserted characters which still exist at at least one commit. Yjs already does something like this.
- kasdi 3y ago
  It seems CRDTs in the limit approach a commit for every keypress. Meanwhile a commit in git is an atomic set of keypresses, to transition from one working state to another. So, in a CRDT world with a commit for every keystroke we would need to annotate sets of commits. Like “all of these commits change the title ‘hello’ to ‘world’”. Would be interesting.

josephg 3y ago

Yeah git bisect is great. And CRDTs on their own probably won’t preserve enough information to allow bisecting to happen - since we don’t know which points in time have working builds. One approach to preserve the ability to bisect would be to allow users to periodically mark points in time with “commits” if they want. The commits wouldn’t be used for synchronisation or merging (since we have the crdt information for that). Instead, they could act semantically much more like anonymous git tags. But they would still be useful as landmarks to mark working builds and milestones. And for git bisect. We could give them associated commit logs. (“Got feature X working”, “Release 1.0.5”, etc). Commits might also be a good way to manage pruning. If users type then delete something, many CRDTs will keep a copy of the deleted characters indefinitely in a log. But we could design it so it only durably persists inserted characters which still exist at at least one commit. Yjs already does something like this.

kasdi 3y ago
It seems CRDTs in the limit approach a commit for every keypress. Meanwhile a commit in git is an atomic set of keypresses, to transition from one working state to another. So, in a CRDT world with a commit for every keystroke we would need to annotate sets of commits. Like “all of these commits change the title ‘hello’ to ‘world’”. Would be interesting.