On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: > On Wed, Dec 15, 2010 at 12:55:27PM -0500, Richard Hipp wrote: > > On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger < > > jo...@britannica.bec.de> wrote: > > > > > On Tue, Dec 14, 2010 at 08:09:58PM -0500, Richard Hipp wrote: > > > > On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine <jos...@letterblock.com > > > >wrote: > > > > > > > > Scenario (2): You are in the middle of a big change when a minor bug > > > report > > > > comes in. You stash your incomplete change, fix the minor bug, then pop > > > > your stash to continue working on your big change. > > > > > > This is actually the main usage I can think of. Consider a minor > > > variation of this. You have done your big change and want to update to > > > the latest version and see that someone else has done a commit in the > > > mean time. When do you merge? First variant is commit first and merge > > > in the second step. This can be done already, but can make it > > > non-intuitive what the commit did, especially if the merge ends up being > > > non-trivial. The other approach is to merge first and commit afterwards. > > > For that second approach, stash is useful. > > > > > > This last sentence is the part I don't get. How is stash any more useful > > here that committing to a branch (public or private) or fork and then > > merging in a separate step? To my mind, it is just yet-another-command to > > have to learn. > > 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 "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 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. - 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. Regards, Lluís. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
