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

Re: stgit, rebasing with 100 patches

From
Karl Wiberg <kha@treskal.com>
Date
Nov 2, 2009, 08:22 UTC
Message-ID
<b8197bcb0911020022k5fefa7f5ia0901af8df0a3604@mail.gmail.com>
In-Reply-To
<9e4733910910040600g2cbd1deah6e7ae3ad9a4aa54e@mail.gmail.com>
On Sun, Oct 4, 2009 at 2:00 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
Show 9 quoted lines
> On Thu, Oct 1, 2009 at 7:04 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> > Is there a better way to locate the patches the got applied?
>
> A solution to this is to make an option on rebase that walks the
> patch stack forward one commit at a time.
>
> What does the --merged option do on stg rebase? The doc is rather
> sparse.

Right, -m/--merged is what you want. Before applying any of the patches, it tries to reverse-apply all of them in reverse order---successful applications mean the patch was already in upstream. It works surprisingly well.

-- 
Karl Wiberg, kha@treskal.com
   www.treskal.com/kalle
Previous: Jon Smirl
Message 3 of 3 in “stgit, rebasing with 100 patches”
  1. Jon SmirlOct 1, 2009
  2. Jon SmirlOct 4, 2009
  3. Karl WibergNov 2, 2009

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.