Subject: Re: [StGit PATCH] edit: Allow setting git tree SHA1 of a patch
Newsgroups: gmane.comp.version-control.git
Date: 2010-05-21 15:29:52 GMT (1 year, 37 weeks, 4 days, 19 hours and 37 minutes ago)
Catalin Marinas <catalin.marinas <at> gmail.com> writes: > On 21 May 2010 14:59, David Kågedal <davidk <at> lysator.liu.se> wrote: >> Catalin Marinas <catalin.marinas <at> gmail.com> writes: >>> 2010/5/16 Gustav Hållberg <gustav <at> gmail.com>: >>>> I would like to have something similar to this patch, which allows for >>>> setting the (git) tree of a particular patch. I would like to use it >>>> (from the Emacs mode) to make it easier to split an old patch into two >>>> (or more). >>>> >>>> It might be that this is too "powerful" (read: unsafe), and maybe a >>>> better (safer) command would use whatever is currently in the index >>>> rather than a SHA1. >>> >>> I'm not against such option (as long as it is somehow mentioned that's >>> dangerous) though I don't fully understand how one would use it, >>> especially when the patch is buried under other patches. With a series >>> of patches, any easily accessible tree (sha1) belongs to one of the >>> patches. >> >> 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). > > This is currently achieved by "pop B C D", edit file, "refresh", "push > --set-tree B C D". Exactly. But I realize that my example was poor, since this will make B revert the change and then C reintroduce it. But perhaps this is actually a defect of the propsed usage model. Gustav, did you think about this? > Can "edit --set-tree <sha1>" make this simpler? One think I can think of is that it doesn't have to worry about modifications to the work tree or the index. > 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). Yes, that would be up to the tool (emacs in this case) to figure out. I could probably give a couple of examples when a user could do it manually, but for those cases the normal push/pop/refresh operations should be good enough. -- David Kågedal