On Wed, Dec 15, 2010 at 11:10:17PM +0100, Joerg Sonnenberger wrote:
> 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.

There is "fossil redo", that should put the working directory in the same state
as before the "undo" (regardless of any later changes after the undo).
Is it?

> 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 think the fossil 'trunk' knows, whether conflicts come from the working
directory or the ckecked out version. The summary after 'merge' could indicate:
X conflicts with the local changes, Y conflicts with the checked out version.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to