{"thread":{"id":"1111","subject":"Merging and parents","startedAt":"2005-07-05T16:19:33Z","lastAt":"2005-07-06T03:26:13Z","messageCount":2,"participants":["Matthias Urlichs","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5670","messageId":"pan.2005.07.05.16.19.28.957617@smurf.noris.de","threadId":"1111","inReplyTo":null,"subject":"Merging and parents","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-05T16:19:33Z","receivedAt":"2005-07-05T16:19:33Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"I just had this ugly merge situation:\n\n M\n |\\\n | \\\n A  B\n |\\/|\n |/\\|\n C  D\n | /\n |/\n E\n\nSuppose both the EC and the ED branch add files (not with conflicting\nfilenames!) which then get modified somewhere between C/D and M.\n\nNo matter which node gets picked as the parent, some files will end\nup as \"created on different branches\" because the chosen parent doesn't\nhave them, even though, strictly speaking, it ain't so.\n\nSo ... what to do? Generate a list of parents, and for each file pick the\none parent where it (a) exists and (b) has the smallest diff?\nOr just ignore (umm... OK, document) the problem?\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nI'm thankful I didn't believe in God, because it\nwould have been another thing for me to conquer.\n\t\t-- Kim Goldman\n"},{"id":"5685","messageId":"Pine.LNX.4.58.0507052011440.3570@g5.osdl.org","threadId":"1111","inReplyTo":"pan.2005.07.05.16.19.28.957617@smurf.noris.de","subject":"Re: Merging and parents","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-06T03:26:13Z","receivedAt":"2005-07-06T03:26:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 5 Jul 2005, Matthias Urlichs wrote:\n>\n> I just had this ugly merge situation:\n> \n>  M\n>  |\\\n>  | \\\n>  A  B\n>  |\\/|\n>  |/\\|\n>  C  D\n>  | /\n>  |/\n>  E\n> \n> Suppose both the EC and the ED branch add files (not with conflicting\n> filenames!) which then get modified somewhere between C/D and M.\n> \n> No matter which node gets picked as the parent, some files will end\n> up as \"created on different branches\" because the chosen parent doesn't\n> have them, even though, strictly speaking, it ain't so.\n\nSo walk me through it. Why is this ugly?\n\nIt's kind of interesting in that it has a merge-base that isn't unique any \nmore: both C and D are \"equally valid\" merge bases, but do it really \ngenerate any real problems?\n\nLet's say that you pick C as the merge base, which means that both A and B \nsuddenly have the same new files show up (that came from D). Now, to make \nit interesting, let's say that D/B also modified that file, so that you \nhave the merge at M see two different files just \"show up\".\n\nThe trivial merger will fail this case, for sure. So I agree that it's a \nproblem for the _current_ stupid merger, but it's not a fundamentally hard \nthing to do per se. Go backwards in history, look for where it was \ncreated, and use that as the merge-base for that particular file. \n\nSo yes, the current merge is very very stupid. It's worked impressively \nwell for the kernel, though, so stupid tends to often be \"good enough\". \nAnd since it _has_ been good enough, I personally haven't been motivated \nto try to improve the merge logic.\n\nBasically, the first-level trivial merge that \"git-read-tree -m\" does is \nreally meant to just cut down the list of files to a manageable level, so \nthat you can do the \"real work\" on a per-file level without being bogged \ndown by having 17,000+ files to work with.\n\nSo if you want to document that the current automatic merge is stupid,\nhey, go wild. It _is_ stupid. It's surprisingly effective, but that may be\nbecause of kernel development patterns and may not be true in other\nprojects.\n\nAnd if somebody wants to write a better merger than the current\ngit-merge-one-file-script, I can only encourage you. I think git has the\npotential to have made the \"normal case\" so cheap that the algorithms in\ngit-merge-one-file-script could be quite advanced, without it slowing down\nthings noticeably. So to some degree I think git should _allow_ for doing\nvery complicated merges, exactly because it efficiently pinpoints the\neffort to the place where it is needed. So a lot of merges that are \ninteresting in theory but aren't _practical_ as a main merge, might \nactually be practical with git.\n\n\t\tLinus\n"}]}