[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Splitting changes
From: |
Óscar Fuentes |
Subject: |
Re: Splitting changes |
Date: |
Thu, 03 Dec 2009 20:47:33 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
[snip]
> So the way my hack works is the following:
> - it takes ("stashes") a copy of the current state.
> - then it lets you make any changes you want (the intention is that
> you're going to revert the changes you want to keep for later).
> You can do this part at any granularity: files, hunks, or even
> by hand.
> - when done, you commit, after which the saved files are re-instated.
This can be achieved with the feature Dan is requesting for Bazaar (and
git already has):
> > 2. something similar to "git stash apply", i.e. apply the shelf but do
> > not remove it. This makes it easy to split changes for example.
With that feature you would do
bzr shelve --all
bzr unshelve --keep # that option would prevent removing the shelve
<hack, hack, hack>
bzr commit etc
bzr unshelve
> This gives me great flexibility, and lets me use any tool I want to
> select which parts to keep and which parts not. So I really like it.
> But it has some serious drawbacks:
> - if the final commit fails because the tree is not uptodate (any more),
> the backend won't know that the update should apply to both the file
> and its "stashed" copy. So you end up having to deal with updates
> missing from the stashed copy, or abort the partial commit
> (i.e. revert to the stashed copy), then update, then re-do the split
> by hand.
>
> - when doing the split by hand, you can make any change you want.
> The intention is for those changes to "undo" part of the local
> changes, but nothing prevents you from adding new changes during this
> time (as you revisit the code to choose how to split your changes, you
> may bump into new opportunities for cleanup and it's sometimes
> difficult to refrain from doing them at that point). And if you do
> add local changes, then these will be undone after commit when the
> saved files are re-instated.
`bzr unshelve' merges the patch it contains, instead of blindly applying
it. It is enough for solving those problems?
[snip]
--
Óscar
- Re: support for bzr shelve/unshelve in vc-dir, (continued)
Re: support for bzr shelve/unshelve in vc-dir, Dan Nicolaescu, 2009/12/03
- Re: support for bzr shelve/unshelve in vc-dir, Óscar Fuentes, 2009/12/03
- Re: support for bzr shelve/unshelve in vc-dir, Bojan Nikolic, 2009/12/03
- Re: support for bzr shelve/unshelve in vc-dir, Dan Nicolaescu, 2009/12/03
- Splitting changes (was: support for bzr shelve/unshelve in vc-dir), Stefan Monnier, 2009/12/03
- Re: Splitting changes (was: support for bzr shelve/unshelve in vc-dir), Eli Zaretskii, 2009/12/03
- Re: Splitting changes, Stefan Monnier, 2009/12/03
Re: Splitting changes,
Óscar Fuentes <=
Re: Splitting changes, Stefan Monnier, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Óscar Fuentes, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Óscar Fuentes, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Dan Nicolaescu, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Óscar Fuentes, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Dan Nicolaescu, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Óscar Fuentes, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Dan Nicolaescu, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Stephen J. Turnbull, 2009/12/03
Re: support for bzr shelve/unshelve in vc-dir, Dan Nicolaescu, 2009/12/03