On Tue, Dec 14, 2010 at 11:42 AM, Joshua Paine <[email protected]>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 [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
