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

Reply via email to