git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: stgit: another way of storing patches

From
Karl Hasselström <kha@treskal.com>
Date
Nov 21, 2007, 11:24 UTC
Message-ID
<20071121112459.GA6592@diana.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
Previous: Jon Smirl
Message 2 of 2 in “stgit: another way of storing patches”
  1. Jon SmirlNov 20, 2007
  2. Karl HasselströmNov 21, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.