> On 21 May 2010 14:59, David Kågedal <davidk@xxxxxxxxxxxxxx> wrote: >> 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 <catalin.marinas@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html