views:

353

answers:

2

Is it possible to emulate the behavior of 'git stash' when using fossil/bzr?

Basically I'm interested in handling the following workflow:

  • at some point the source code tree has state X, it is commited
  • I proceed to writing new code, I write it for a while and I see the opportunity of a refactoring
  • I can't commit at this point, because the change I've started to make is not completed, it is not atomic yet
  • at this point I would do 'git stash', would save the current work and would get back to state X
  • I would do the refactoring and commit, source code now has state Y
  • I would merge source code in state Y with code in stash, complete the change to make it atomic, then commit once again, pushing the source code to state Z

I think that generally it is possible to emulate this scenario when using another SCM by branching the code in state X instead of doing 'git stash', doing the refactoring in that branch, then merging the branch back into the main one. But I'm aware that branching is not always a cheap operation. So are there any better particular approaches that eventually rely on specific features of fossil/bzr?

+4  A: 

Use bzr shelve and bzr unshelve commands.

bialix
+2  A: 

You can use the patch command of your system.

  • First you make a "stash" by storing a generated diff as .patch file:

    $scmtool diff > working.patch

  • then reset your working directory.

  • later, apply the patch with:

    patch -p1 --dry-run < working.patch

  • and then this works, remove the --dry-run to apply the patch for real.

vdboor
The question was about bzr, not git!
Randal Schwartz
@Randal - You're missing the point. vdboor has lowered the requirements from needing a stash/shelve feature to needing a diff feature in the SCM. This'll work with anything, and now the 'fossil' part of the OP has been answered.
teepark
@teepark thank you for your support, I've updated the post to make this more obvious
vdboor