4 ms·
The piece of BitKeeper I wish people would steal is the smerge gca conflict format. See https://www.bitkeeper.org/man/smerge.html https://www.bitkeeper.org/man
by wscott 3y ago
The piece of BitKeeper I wish people would steal is the smerge gca conflict format. See https://www.bitkeeper.org/man/smerge.html https://www.bitkeeper.org/man/smerge.html
Example:
<<<<<<< local slib.c 1.642.1.6 vs 1.645
sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
- assert(sc->tree);
- sccs_sdelta(sc, sc->tree, file);
+ assert(HASGRAPH(sc));
+ sccs_sdelta(sc, sccs_ino(sc), file);
<<<<<<< remote slib.c 1.642.1.6 vs 1.642.2.1
- sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
+ sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
assert(sc->tree);
sccs_sdelta(sc, sc->tree, file);
>>>>>>>
Here we have a code conflict and rather than showing you what the file looks like on the two sides it shows you what was changed on both sides relative to the GCA. So we get two unified diffs. The local side made this edit, while on the remote side we had that edit. Then it is obvious how to resolve the conflict without losing a change.
This works for the cris-cross case because that GCA is really a set of common revisions merged together.
- gavinhoward 3y agoI'm making a VCS based on the weave. Your wish will be answered; I wanted a conflict-aware format, and I will definitely plunder the smerge format.
- teraflop 3y agoGit has something similar if you turn on the "diff3" conflict style, and I can't for the life of me understand why it's not on by default, because there are many situations where you just don't have enough information to properly resolve a merge without it.
- pabs3 3y agoBTW zdiff3 is a newer version of that style that is slightly better than diff3.
- juped 3y agozdiff3 is NOT "better", it's a matter of personal preference. it moves common lines out of the conflicted hunks, which may be highly confusing. some people use it anyway
- wscott 3y agoThe "diff3" style looks like this: <<<<<<< HEAD sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj); assert(HASGRAPH(sc)); sccs_sdelta(sc, sccs_ino(sc), file); ||||||| merged common ancestors sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj); assert(sc->tree); sccs_sdelta(sc, sc->tree, file); ======= sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p); assert(sc->tree); sccs_sdelta(sc, sc->tree, file); >>>>>>> c4892343...... That contains the same information, but you have to parse it yourself and it is not nearly as fast to see what changed. However, it is faster to edit since you don't need to remove the diff markers.
- juped 3y agoIf you ask on / search the history of the mailing list, you'll see that in complex merges with synthetic intermediate parents it can produce some really gnarly output, which is the main reason why (coupled with git's general conservatism).
- tome 3y ago> turn on "diff3" ... there are many situations where you just don't have enough information to properly resolve a merge without it That's right. Here's an example I wrote up: https://stackoverflow.com/a/63739655/997606 https://stackoverflow.com/a/63739655/997606