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

Re: bug?: stgit creates (unneccessary?) conflicts when pulling

From
CMCatalin Marinas <catalin.marinas@arm.com>
Date
Mar 1, 2006, 10:59 UTC
Message-ID
<tnx1wxmig75.fsf@arm.com>
In-Reply-To
<20060227222600.GA11797@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
Show 11 quoted lines
> Karl Hasselstr?m <kha@treskal.com> wrote:
>> If I make a patch series where more than one patch touches the same
>> line, I get a lot of merge errors when upstream has accepted them and
>> I try to merge them back.
>
> When pg grabs its (possibly remote) parent ("stg pull" aka pg-rebase)
> we try to push down PatchA.  If PatchA fails to push cleanly we'll
> pop it off and try to push PatchA + PatchB.  If that pushes cleanly
> then we fold the content of PatchA into PatchB, effectively making
> PatchA part of PatchB.  If PatchA + PatchB failed to push down
> cleanly then we pop both and retry pushing PatchA + PatchB + PatchC.

How do you solve the situation where only PatchA, PatchC and PatchE were merged, B and D still pending? Trying combinations of patches is not a good idea.

As I said, if you have a big number of patches this might be pretty slow. Have a look at my patch for trying the reversed patches in reverse order. It seems to solve this problem for most of the cases. There are cases when this method would fail like adjacent changes made by third-party patches that break the context of the git patches and git-apply would fail. An addition to this would be to try a diff3 merge with the reversed patch but I don't think it's worth since it would become much slower.

> If that pushes down cleanly then we make PatchA and PatchB officially
> part of PatchC.

I don't agree with this. For example, patches A, B and C change the same line in file1 but patch A also changes file2 and patch B changed file3. With your approach, merging A+B+C succeeds and you make A and B part of C and hence move the changed to file2 and file3 in patch C.

The above can happen when the maintainer only merges part of the patch or simply decides to merge patch C only and manually solve the conflict in file1 (since patch C is based on the context from patches A+B).

-- 
Catalin
Previous: Shawn PearceNext: Shawn Pearce
Message 14 of 22 in “bug?: stgit creates (unneccessary?) conflicts when pulling”
  1. Karl HasselströmFeb 27, 2006
  2. Sam VilainFeb 27, 2006
  3. Catalin MarinasFeb 27, 2006
  4. Catalin MarinasFeb 28, 2006
  5. Catalin MarinasFeb 28, 2006
  6. Catalin MarinasFeb 28, 2006
  7. Chuck LeverMar 1, 2006
  8. Catalin MarinasMar 1, 2006
  9. Karl HasselströmMar 3, 2006
  10. Catalin MarinasMar 3, 2006
  11. Karl HasselströmMar 3, 2006
  12. Catalin MarinasMar 3, 2006
  13. Shawn PearceFeb 27, 2006
  14. Catalin MarinasMar 1, 2006
  15. Shawn PearceMar 1, 2006
  16. Catalin MarinasMar 1, 2006
  17. Shawn PearceMar 1, 2006
  18. Catalin MarinasMar 9, 2006
  19. Junio C HamanoMar 9, 2006
  20. Catalin MarinasMar 10, 2006
  21. Junio C HamanoMar 11, 2006
  22. Shawn PearceMar 10, 2006

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.