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

Re: rebase drops patches that have since been reverted

From
Johannes Sixt <j6t@kdbg.org>
Date
Jun 12, 2019, 16:55 UTC
Message-ID
<2033f2fe-cc01-d7a6-bac3-4ba982a68425@kdbg.org>
In-Reply-To
<CA+49okrxjv63UQfQ1fMt6xC95Pjz2wuZu70WMS94vukTHevEaw@mail.gmail.com>
Am 12.06.19 um 17:03 schrieb Shawn Landden:
Show 5 quoted lines
> If a patch has been applied upstream AND THEN reverted, rebase still
> drops the patch, requiring the use of relative rebase git rebase -i
> HEAD~5 et cetera.
> 
> git rebase should detect reverts as well.

You have the same patch that upstream has. Perhaps you cherry-picked it from them, or they cherry-picked it from you. In any case, they thought the patch was a good one.

Later upstream found a problem with the patch and decided to revert it. Certainly, they didn't do this just for fun; they had a good reason.

Now you are rebasing against upstream. IOW, you are accepting the authority of the upstream code. Then, why on earth would you not want to accept their authorative word that the cherry-picked patch was bad and needed to be reverted?

If you later find out that your patch is definitely needed, then it is on you to prove that, for example, by including it again in your patch series. That must be an explicit decision on your part, not an accident that happens.

TLDR: Git worked as designed.
-- Hannes
Previous: Shawn Landden
Message 2 of 2 in “rebase drops patches that have since been reverted”
  1. Shawn LanddenJun 12, 2019
  2. Johannes SixtJun 12, 2019

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.