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

Re: inexplicable failure to merge recursively across cherry-picks

From
David Brown <git@davidb.org>
Date
Oct 10, 2007, 15:48 UTC
Message-ID
<20071010154831.GA19226@old.davidb.org>
In-Reply-To
<alpine.LFD.0.999.0710100808150.3838@woody.linux-foundation.org>
On Wed, Oct 10, 2007 at 08:25:15AM -0700, Linus Torvalds wrote:
Show 11 quoted lines
>Yes, *some* SCM's have tried to do that. In particular, the ones that are 
>"patch-based" tend to think that patches are "identical" regardless of 
>where they are, and while re-ordering of them is a special event, it's not 
>somethign that changes the fundamental 'ID' of the patch.
>
>For example, I think the darcs "patch algebra" works that way.
>
>It's a really horrible model. Not only doesn't it scale, but it leads to 
>various very strange linkages between patches, and it fails the most 
>important part: it means that merges get different results just because 
>people are doing the same changes two different ways.

Actually, specifically darcs, different merges _always_ result in the same data. It's a fundamental part of is patch algebra. No matter what order you apply a given set of patches, even with conflicts and reordering, you always get the same result, or no result. Conflicts are "resolved" by inserting conflict markers in the file, ordered by the patch ID. It doesn't matter which order you apply them in, you get the same markers. Then there will be a merge patch which fixes the markers that someone could apply, no matter what order the applied the previous patches.

Darcs breaks down in a few places, though.
   - The no result.  Sometimes, it just can't figure out how to reorder
     patches.  Even worse, occasionally, the implementation will fail to
     terminate try to figure this out.  There isn't much to do at this
     point, except manually apply the patch, hence generating a new patch
     ID.
   - It doesn't scale well.

The strange linkages between patches could be thought of as a feature, since it is basically constraining the order that the patches can be applied in.

There is a darcs-git project that tries to do the darcs things on top of git.

Dave
Previous: Linus TorvaldsNext: Miklos Vajna
Message 6 of 11 in “inexplicable failure to merge recursively across cherry-picks”
  1. martin f krafftOct 10, 2007
  2. Linus TorvaldsOct 10, 2007
  3. martin f krafftOct 10, 2007
  4. David KastrupOct 10, 2007
  5. Linus TorvaldsOct 10, 2007
  6. David BrownOct 10, 2007
  7. Miklos VajnaOct 10, 2007
  8. Linus TorvaldsOct 10, 2007
  9. Miklos VajnaOct 11, 2007
  10. Sam VilainOct 11, 2007
  11. Linus TorvaldsOct 11, 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.