5 ms·

Git 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 man

Git 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 ago
BTW zdiff3 is a newer version of that style that is slightly better than diff3.
- juped 3y ago
  zdiff3 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 ago
The "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 ago
If 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

pabs3 3y ago

BTW zdiff3 is a newer version of that style that is slightly better than diff3.

juped 3y ago
zdiff3 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 ago

The "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 ago

If 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