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

From: David Kågedal <davidk@lysator.liu.se>
Date: May 21, 2010, 13:59 UTC
Message-ID: <u5tzkzt73us.fsf@beatles.e.vtech>
In-Reply-To: <AANLkTikcG3Chw1cpiKB00MrnZz-HZk9xAF_KtTTiVECi@mail.gmail.com>

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

Show 17 quoted lines

> Hi Gustav,
>
> 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).

Working like this means that we don't really see the series as a string of pateches, but as a series of named commits that we can go back and edit. But this is a natural way of working with it once the tools get powerful enough to support it.

-- 
David Kågedal