On Dec 15, 2010, at 16:53 , Joerg Sonnenberger 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. An alternative idea would be > think about it in terms of a patch queue.
Actually what I do is (I install fossil as fl): 1) work freely on my big change, committing atomic changes fl commit --private fl commit --private [...] fl commit --private 2) prepare to make a "real commit" fl up trunk fl merge private 3) make sure everything works as expected, commit to the world fl commit This feels intuitive and does not leave space for disaster. Furthermore, at step 3 you can see an aggregated diff of the final shape of your big change. And yes, I think of it as a patch queue. How would a "stash" add value? Apart from the fact, that you have to clone to a new repo to get rid of old private commits. Kind regards, Remigiusz Modrzejewski _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
