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

Re: stgit, rebasing with 100 patches

From
Jon Smirl <jonsmirl@gmail.com>
Date
Oct 4, 2009, 13:00 UTC
Message-ID
<9e4733910910040600g2cbd1deah6e7ae3ad9a4aa54e@mail.gmail.com>
In-Reply-To
<9e4733910910011604w68cdca86l2baa2f2fe4db4a32@mail.gmail.com>
On Thu, Oct 1, 2009 at 7:04 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
Show 11 quoted lines
> I have 100 patches loaded into in stgit. My tree is at 2.6.30. Now I
> want to rebase to 2.6.31-rc1. About 30 of these hundred patches got
> committed in this interval.
>
> If I rebase directly to 2.6.31-rc1 I end up with a bunch of merge
> conflicts as the patches are applied. That's because patches 'a,b,c'
> got applied in the merge window. When I push 'a' back down it sees the
> combination of 'a,b,c' not just 'a'. It is unable to figure out that
> 'a' was applied and then 'b' and 'c' applied on top of it.
>
> 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.
-- 
Jon Smirl
jonsmirl@gmail.com
Previous: Jon SmirlNext: Karl Wiberg
Message 2 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.