Have set up a master git repo and a mirror of it. After some experiments I detected a typical conflict resolution (mis)managment: without a warning, git just dropped conflicting commits -- a pretty much insane default setting.
After some perusing of SO, I tried
git config receive.denyNonFastForwards 1
git config receive.denyDeletes 1
but that does not solve the lost commit issue. When there are two conflicting commits in the master and in the mirror repo,
git remote update
git push --mirror
on the mirror overwrites the corresponding commit on the mirror. If you are lucky, the one who committed the deleted commit will detect this during his next pull.
Are there any other config options to either prevent forced updates/deletes, or to commit the whole conflict such that the next one to pull is able to resolve it no matter if he took part in producing the conflict or not?
Are there better SCMs out there? Or more precise: are there SCMs that handle conflict resolution more safely when being run in a distributed environment? Example: why not record two or more commits as "parallel" and let one of the next editors bring them back together? One could describe such a behavior as "auto branching". The equivalent of a "git pull" would then detect the new upstream branching point and require the user to decide which way to go....