On Sat, Dec 10, 2022 at 11:09:55PM +0100, Uwe Brauer wrote: [...] > [1] We tried out well mercurial not git for some weeks but most of my > collaborators find the idea of merging strange in the sense they > expected the server to merge conflicts for them, and that is I thing why > subversion is still around, it feels more natural for quite some people.
The problem with server-side merges is that, so to speak, "no one has seen the merged state". I mean, while VCSes implement clever algorithms for merging, they just combine lines of text, nothing more: to my knowledge, there exist no algorithms in popular systems which would somehow prove the result of the merge is _sensible;_ at best a VCS may be coupled with a CI system which would run a test suite or at least verify the project builds (or whatever sanity check is possible if the project is not about software of anything else "buildable"). Well, with DVCSes, these days it's not too much different as many teams do Subversion style server-side merges by clicking buttons in their Git hosting front-ends such as GitLab - technically to much the same effect. My team at my $dayjob does this, too, and the situations when the merge goes well but the result is subtly botched do happen from time to time. (Actually, we use self-hosted GitLab, and since some time GitLab learned to detect that a branch bound to a merge request (it's akin to a "pull request" in Github's parlance) was merged manually and reflects that in the corresponding MR - marking it merged, but we're slow at adopting this feature.) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20221211103208.rkk3okev6s25fre2%40carbon.
