Hi, I'll say a few things since I was one of those who said "git stash" in a post :)
"git stash", I think, is not a necessity but a convenience. There is nothing that you can do with git stash that you can't do with branches. > Scenario (1): git-pull (the equivalent of "fossil update" in this context) > will not pull in upstream changes due to merge conflicts. So you stash your > local changes, then git-pull, then pop your stash. > > But Fossil has no problem pulling in upstream changes and simply marking the > conflicts. And if you do a "fossil update" and you don't like all the > conflicts you get, you can always "fossil undo" to go back to what you had, > then commit your changes to a branch and work the conflicts out in a bunch > of little merges, if that's what you'd prefer to do. One way to look at the git stash is as a private infinite undo tree. Despite the equivalence of actions of the scm systems, my mind thinks differently with git stash vs any step requiring undo. With stash, it is very obvious to me that absolutely nothing is lost, not even temporarily. If there were infinite undo in fossil, thoughts of disaster can be put to rest very easily. However, with only one level of undo, I don't feel comfortable about relying on undo to not lose work. Sometimes I type commands mechanically and so can't recall what exactly "fossil undo" will do. > 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. > > In Fossil, you can do this using "fossil commit -private" to create a I'd never used commit --private, so I just tried it. After the commit, the state of the checkout is the latest code. Whereas after a stash, the state of the checkout is that of the code *before* your changes. So a stash is a commit followed by a checkout of the earlier version. Again .. that stash combines the two steps in one command is a convenience, not a necessity. As for scenario (3), you're right. Fossil doesn't need stash to do this. Regards, -Kumar On Wed, Dec 15, 2010 at 9:09 AM, Richard Hipp <d...@sqlite.org> wrote: > > > On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine <jos...@letterblock.com> > wrote: >> >> It would be nice to have something like `git stash`, too. Probably the >> biggest thing I miss from git. >> > > I've been reading up on git-stash to see if Fossil needs a similar feature. > So far I don't see the need, since stash doesn't do anything that Fossil > doesn't already handle more or less automatically. Please enlighten me if > I'm missing something obvious.... > > Several cases where the git-stash manpage and other resources recommend > using git-stash are shown below, together with how you would do the same > thing in Fossil (without a stash). > > Scenario (1): git-pull (the equivalent of "fossil update" in this context) > will not pull in upstream changes due to merge conflicts. So you stash your > local changes, then git-pull, then pop your stash. > > But Fossil has no problem pulling in upstream changes and simply marking the > conflicts. And if you do a "fossil update" and you don't like all the > conflicts you get, you can always "fossil undo" to go back to what you had, > then commit your changes to a branch and work the conflicts out in a bunch > of little merges, if that's what you'd prefer to do. > > 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. > > In Fossil, you can do this using "fossil commit -private" to create a > private unpushable branch to store your incomplete change. I don't see how > git-stash is any easier than "fossil commit -private". In fact, it seems > that "commit -private" is a little easier since it does not require learning > a new mechanism (stash versus commit) but rather just a variation on an > existing mechanism (commit) which presumably you already know very well. > > Scenario (3): You start out making changes but later decide that you want to > put those changes on a branch, so you git-stash, then git-branch-new to > create the new branch, then git-stash-pop, then git-commit. > > In Fossil, all that extra work is not necessary. You can commit to a branch > at any time simply by adding the --branch argument to the "fossil commit" > command line. And, you can even move a check-in that is already committed > into a new or different branch using the check-in-edit feature of the > "fossil ui" command. Fossil treats all check-ins as belonging to a single > global DAG. Branches are designated using tags, which can be changed and > rearranged after-the-fact. Git, on the other hand, appears to keep a > separate DAG for each branch, meaning that checkins cannot be so easily move > from one branch to another, necessitating tricks like the use of stash. > > So in summary - Fossil appears to already do everything that git-stash does > and do it at least as easily as git-stash. Furthermore, I think for the > sake of usability that is important to keep Fossil as simple as possible and > avoid adding unneeded features. And for those reasons, I'm thinking it > would not be a good idea to add a stash to Fossil. But I am open to > arguments to the contrary. > > What say you? > > > > -- > D. Richard Hipp > d...@sqlite.org > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
