Re: [StGit PATCH] edit: Allow setting git tree SHA1 of a patch

From: David Kågedal <davidk@lysator.liu.se>
Date: May 21, 2010, 15:29 UTC
Message-ID: <u5twrux6znz.fsf@beatles.e.vtech>
In-Reply-To: <AANLkTilV3VQARdyZ-m9GCXz1Rwt0j6Q6noNyFrmmDzR5@mail.gmail.com>

Catalin Marinas <catalin.marinas@gmail.com> writes:

Show 29 quoted lines

> On 21 May 2010 14:59, David Kågedal <davidk@lysator.liu.se> wrote:
>> Catalin Marinas <catalin.marinas@gmail.com> writes:
>>> 2010/5/16 Gustav Hållberg <gustav@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