But, what if the two forks become incompatible when merged? For your proposed
auto-merge to work, it’s enough that the two forks simply touch (alter)
different files.
An auto-merge would obviously work without producing conflicts as neither fork
touches files touched by the other fork.
Now, it’s quite possible that either fork which built OK before the merge, no
longer does.
The simplest example is to consider as a sole change the addition of a new file
in fork 2 which depends on an external function name called xxx(). Fork 1,
however, has just changed that function from xxx() to yyy(). Neither fork will
compile anymore (assuming the new file is now part of the build process).
It seems that merging can only be done manually, as only a human can know the
implications of the changes in the merged files.
Disclaimer: I may have misunderstood your suggestion.
From: Matt Welland
It would be very cool if on update if a fork was detected it was (optionally)
automerged. If the merge had conflicts then it would be rolled back and the
user notified.
Forks in fossil are an artifact of a distributed system trying to pretend it is
centralized. Auto fork correction might help maintain the illusion of being
centralized.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
