On Wed, May 08, 2013 at 01:01:42PM +0200, Stephan Beal wrote: > On Wed, May 8, 2013 at 12:56 PM, Lluís Batlle i Rossell > <[email protected]>wrote: > > > In fact, I don't see why most VCS tend (somehow propose) to *not commit* > > merge > > conflicts before solving the conflicts. That makes the conflict solution > > 'disappear' from the timeline. > > > > I think it's fine in committing the conflict marks, and then the solution > > be an > > explicit extra checkin. The wiki and tickets could work that way. > > > > But in the wiki it can't work that way at the moment - they are committed > as soon as you click save. If we were to do a proper merge at that point we > would have no choice but to either NOT save the changes (returning to the > editor with the conflict-marked version), or to save the conflicted > version. The first option has other side effects (e.g. it would affect > "fossil wiki commit pageName FILENAME"). In an automated process the second > option would produce conflicts which probably largely go unnoticed.
There could be some kind "auto-merge-leaves". Would that work? _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
