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

Re: Newbie question regarding 3way merge order.

From
Sitaram Chamarty <sitaramc@gmail.com>
Date
Jan 31, 2009, 00:32 UTC
Message-ID
<slrngo771p.b1i.sitaramc@sitaramc.homelinux.net>
In-Reply-To
<87vdrwbofv.fsf@gigli.quasi.internal>
On 2009-01-30, Raimund Berger <raimund.berger@gmail.com> wrote:
> E.g. with A, B and ancestor C, the merging and conflict resolution
> algorithm had to be completely symmetric if diff(A,C)+diff(B,C) applied
> to C should always be the same as diff(B,C)+diff(A,C) applied to C.
> So I'm really asking if that is a fact upon which I can rely.

I've always relied on it :-) Or, to put it another way, I've never come been bitten by this issue.

> An interesting hint. Up to now, I assumed that rebase would always
> perform implicit merging strategies. I mean what else would one expect
It does.
Show 5 quoted lines
> in the above picture to happen when rebasing A on B? I'd assume it'd
> produce the same tree as a merge of A into B, by employing exactly the
> same machinery. E.g. fast forward of C to B, then merge A in. So that,
> effectively, the only difference between rebase and merge is just commit
> history but not (tree) content.

This is also true. For example, "git help pull" offers an option to use rebase instead of merge.

> From reading the rebase man page though it seems that merging machinery
> has to be explicitly requested via '-m'. Which makes me wonder how the
> default rebase actually works.

No. I think the documentation is not sufficiently clear. Everything else in "git help rebase" (look for the string "strateg") tells me that the default, if you don't specify anything at all, is the recursive merge strategy. Since "-s" implies "-m", I'm not sure what -- if anything -- is achived by "-m" all by itself.

When I get some time I'm planning to look at the test scripts and simulate them without "-m" to see what differences there are; I'd assume a test script set up to test the proper operation of rebase --merge should be using a test case whose result differs if you dont use --merge!

> Mathematically speaking, if A1 and A2 commute with regard to a binary
> operation, A1 ... An do as well. So I'd still think the latter question
> boils down to the commutativity question above *iff* rebase actually
> does an implicit merge by default. Which I'm now led to question.

Rebase *does* do an implicit merge by default (as far as the tree that results is concerned, which you mentioned right at the start), I'm pretty sure of it.

Perhaps someone with more git smarts will chip in with something more concrete.

Previous: Raimund BergerNext: Raimund Berger
Message 5 of 16 in “Newbie question regarding 3way merge order.”
  1. Raimund BergerJan 29, 2009
  2. Raimund BergerJan 30, 2009
  3. Sitaram ChamartyJan 30, 2009
  4. Raimund BergerJan 30, 2009
  5. Sitaram ChamartyJan 31, 2009
  6. Raimund BergerJan 31, 2009
  7. Nanako ShiraishiJan 31, 2009
  8. Raimund BergerFeb 1, 2009
  9. Junio C HamanoFeb 1, 2009
  10. Sitaram ChamartyFeb 2, 2009
  11. Raimund BergerFeb 2, 2009
  12. Johannes SixtFeb 2, 2009
  13. Raimund BergerFeb 2, 2009
  14. Johannes SixtFeb 3, 2009
  15. Nanako ShiraishiJan 31, 2009
  16. Raimund BergerJan 31, 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.