On 21 May 2010 14:59, David Kågedal [off-list ref] wrote:
quoted
The idea is that Gustav wants to allow the editing of a file as it
appears in an earlier version. Lets say you have patches A, B, C and
D. You realize that one of the changes in to foo.c in C shuold really be
done in A. So you open the "A version of foo.c" in your editor, do the
change, and then save it. The save operation needs to update A to be
the new tree that contains the updated foo.c, and the remaining patches
will keep their tree. The effect is that the moved change now appears as
a diff in A, but not in C (nor B or D).
David's example does not exactly describe the situation I have in
mind. I was only envisaging the possibility to move a change from one
patch to one of its neighbours. This is enforced by keeping all other
trees intact.
On Fri, May 21, 2010 at 5:16 PM, Catalin Marinas
[off-list ref] wro> This is currently achieved by "pop B
C D", edit file, "refresh", "push
--set-tree B C D".
Can "edit --set-tree <sha1>" make this simpler? Which <sha1> value
would be used with "edit --set-tree" (unless that's done by Emacs mode
behind the scene and it generates the tree that gets passed to edit).
This is indeed my assumption. Without a "smart" user interface to hide
the intricacies this operation becomes too complicated. At least
unless you work exclusively with the index. My prototype for the Emacs
mode approximately does 'read-tree <old patch sha1>', 'update-index
--cache-info <new blob>', 'stg edit --set-tree $(write-tree)'.
I actually think it is the use of the Emacs user interface that really
enabled us (me and my colleagues) to see the stack as a living set of
changes that are very easy to edit. This lead to the conclusion that
one wants to make it much easier, light-weight and faster to move
individual changes between (for a start, neighbouring) patches.
As you point out, there are a number of ways to do these things
already; this is all about making it very easy.
- Gustav