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

merge -s ours question

From
Jay Soffian <jaysoffian@gmail.com>
Date
Mar 8, 2010, 22:26 UTC
Message-ID
<76718491003081426j4329e322we91fc6fe13f2d03@mail.gmail.com>
Here's the scenario,

I have a muddled development branch that has a mix of local development and upstream merges:

 upstream 1--2--3--4--5
           \     \     \
      dev   o--A--x--B--x ... Y

It took a lot of work, but I backported everything newer than A using rebase and cherry-pick, and omitting the merges, giving me a dev' clean of merges from upstream:

     dev'   o--A'--B' ... Y'
           /
 upstream 1--2--3--4--5
           \     \     \
      dev   o--A--x--B--x ... Y

Now it turns out that going forward, I need two development branches, one that's based on a newer version of upstream for which the merge work was already done in the original dev. In an ideal world I'd have this history:

upstream 1--2--3--4--5
          \           \
    dev2   \           o--o--o--o
            \
    dev1     o--o--o--o--o

And I would periodically merge dev1 into dev2 (dev2 requires the work being done on dev1). The problem is that my backported dev' has a mix of dev1 and dev2 and it's impossible for me to tease them apart at this point. So my plan was to do this:

     dev'   o--A'--B' ... Y'
           /               \
 upstream 1--2--3--4--5     \
           \     \     \     \
      dev   o--A--x--B--x ... Z

Where Z is created using using "git merge -s ours dev'". Is it correct that this should do nothing more than give me a new merge base for dev and dev'? Then going forward I can merge from dev' to dev per usual.

Thanks,
j.
Next: Junio C Hamano
Message 1 of 3 in “merge -s ours question”
  1. Jay SoffianMar 8, 2010
  2. Junio C HamanoMar 8, 2010
  3. Jay SoffianMar 8, 2010

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.