Hacker News new | past | comments | ask | show | jobs | submit login

The piece of BitKeeper I wish people would steal is the smerge gca conflict format. See 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.




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.


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.


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


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


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).


> 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


I'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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: