# stgit: another way of storing patches

2 messages from 2007-11-20 to 2007-11-21. Participants: Jon Smirl, Karl Hasselström.
Thread: https://gitlist.dev/t/10943

## Jon Smirl, 2007-11-20 14:53

Subject: stgit: another way of storing patches
Message-ID: <9e4733910711200653g4d87c433gae2d48f3508940f5@mail.gmail.com>
URL: https://gitlist.dev/e/9e4733910711200653g4d87c433gae2d48f3508940f5%40mail.gmail.com

```
What about storing each stg git patch in a branch and then
auto-merging them into the working copy? That would allow per patch
history and undo. Would it make them easier to share? You could use
tag names to tell stg how to merge and make the working branch.

-- 
Jon Smirl
jonsmirl@gmail.com

```

## Karl Hasselström, 2007-11-21 11:24

Subject: Re: stgit: another way of storing patches
Message-ID: <20071121112459.GA6592@diana.vm.bytemark.co.uk>
URL: https://gitlist.dev/e/20071121112459.GA6592%40diana.vm.bytemark.co.uk
In-Reply-To: <9e4733910711200653g4d87c433gae2d48f3508940f5@mail.gmail.com>

```
On 2007-11-20 09:53:55 -0500, Jon Smirl wrote:

> What about storing each stg git patch in a branch and then
> auto-merging them into the working copy?

You mean making a "patch" be a topic branch rather than just one
commit, with the successive commits on the topic branch reflecting the
changes to the patch over time?

How would you handle operations such as refreshing a non-topmost
patch, reordering patches, dropping patches, etc? It seems to me that
the operation you'd want then would look more like cherry-picking than
merging, at least sometimes.

It might work, but someone would have to sit down with pen and paper
and work out how all the common operations should work.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

```