emacs-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]