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. > An alternative idea would be > think about it in terms of a patch queue. > > Joerg > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
