On Wed, Dec 15, 2010 at 12:55:27PM -0500, Richard Hipp wrote: > On Wed, Dec 15, 2010 at 10:53 AM, Joerg Sonnenberger < > [email protected]> 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 <[email protected] > > >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. Joerg _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
