On Wed, Dec 15, 2010 at 10:50:52PM +0100, Lluís Batlle i Rossell wrote: > On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: > > Having incomplete changes in the tree is bad for things like bisect. > > It shouldn't be forced. The big issue here is that merging changes the > > working copy. If you can make it possible that automatic merges can be > > done directly, without changing the working copy, that would be good > > enough for this purpose. > > I prefer the current "fossil undo" option (with later commit to a branch), > and I don't like much those automatic merges done directly, unless they are > optional.
The trouble with "fossil undo" is that it throws away the state at some point, e.g. it very volatile and I wouldn't trust it with my data. Automatic merge + commit should definitely be optional behavior. It might make sense to use it as default and fall back to "manual" merging otherwise. > The "fossil undo" + new branch, for those who believe in saving as much as > possible in the history of the file tree, even encourages the public > resolution > of the merge. For those not wanting to save that publicly, those can even use > "-private". I would prefer to know in advance whether I can merge without problems or not. Problems against the base revision, not the working copy. This is important to decide whether I have to get a new working copy to do the merge, especially when working on a private branch. > I don't think we need 'stash'; at most, I think we would get advantage of: > - a precise description of what "fossil undo" is going to do in any case. > Maybe it > is only my trouble, but I'm not sure what will happen if I run "undo" after > I > changed things after "fossil merge", for example. Ack. > - and a reliable way of detecting if the merge is trivial or not, to be able > to to > undo + branch as soon as possible in case of non triviality. The recent > improvement on notifying conflicts goes in that direction, I think. Ack. Joerg _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users