On 21 May 2010 16:32, Gustav Hållberg <gustav@xxxxxxxxx> wrote: >> 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. Yes, that's something commonly needed. > 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)'. OK. As I said, I don't have a problem with the patch. Maybe you could mention in the help that it's usually meant for tools like Emacs, otherwise people would wonder how to use it from the command line but as it is, the patch looks fine. > 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. I try to reduce the patch editing as much as possible since I need to have some public branches that have an immutable history (hence the stg publish command). BTW, since you are a group of people using stgit, have you found a useful way to share patches/series easily? For example, one colleague works on a set of patches and I'd like his included in my series but I don't want me to maintain those, so periodically I would have to re-import his patches. There is a way to use a combination of export and sync but it's not always easy to follow. StGit has the patches (diffs) in the a *.stgit branch but solving conflicts in diff is problematic, so not sure how to use that for easy synchronisation. -- Catalin -- 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