Local edits being lost seems the wrong thing to do, even if they are recoverable with an undo action - undo doesn't always do what I expect, which is probably user error, but since undo is only one level deep st also seems that if they are not recovered immediately, they would be lost forever.
What if an implicit check-in was done to any files that would be affected by the merge (whether deleted or merely edited) imediately before the merge? Local edits would then be a fork preserved in the repository, and "undo" wouldn't actually be undoing anything, but rather reverting to that forked version. -J Richard Hipp wrote: > Suppose you have the "trunk" branch checked out and you have made > changes to file xyz.txt locally, but have not checked them in. Then you > do a merge of branch "other-branch": > > fossil merge other-branch > > The file xyz.txt has been deleted in other-branch. What should fossil's > response be? Should it retain the locally edited copy of xyz.txt, or > should it delete file xyz.txt? > > If you have not made any local edits to xyz.txt when you do the merge, > then Fossil will delete the file. That seems like the right thing to > do. But I'm less clear on what the right thing to do is if you have > made local edits. Suggestions are appreciated. > > Please remember that by "delete the file" you are not really losing any > information. Historical versions of the file remain in the repository > forever. And even if your local edits are deleted, they can be > recovered using "fossil undo". _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
