{"thread":{"id":"2657","subject":"Problem merging","startedAt":"2005-11-23T02:50:01Z","lastAt":"2005-11-27T21:24:44Z","messageCount":10,"participants":["Luben Tuikov","Junio C Hamano","Fredrik Kuivinen","Johannes Schindelin","Ben Clifford","Andreas Ericsson","H. Peter Anvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12587","messageId":"20051123025001.15527.qmail@web31812.mail.mud.yahoo.com","threadId":"2657","inReplyTo":null,"subject":"Problem merging","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2005-11-23T02:50:01Z","receivedAt":"2005-11-23T02:50:01Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"Ok, background:\n\nI've two branches of the same .git, _but_ they live in\ndifferent directories (bearing the branches' names)\nwith different index caches, but with the same identical\nobjects directory (different HEADs of course).\n(in effect, I have both branches \"checked out\")\n\nBranch A is the \"trunk\", branch B is trunk+my changes.\nI do:\n\nbranchA: git pull \nbranchA: cd ../branchB/\nbranchB: git resolve HEAD branchA \"merge trunk\"\n\nAnd I get:\n\nTrying to merge 4b4a27dff4e2d4cc2eac1cde31aede834a966a48 into\ne1ef47b54d7e7e477f7f1eb3251a9d37f38e0469 using 989e4d6cbc69191c41ddf4b1c492457410376b43.\nSimple merge failed, trying Automatic merge\nRemoving include/asm-um/ldt.h\nfatal: merge program failed\nAutomatic merge failed, fix up by hand\n\nThis is with git HEAD: \n2392ee98eb76aa821de53c93c9e36acb18d27fc0 -- latest as\nof now.\n\nIs this a bug in git? Since this process has always worked\nbefore.\n\nThanks,\n Luben\n"},{"id":"12588","messageId":"7v4q6483ms.fsf@assigned-by-dhcp.cox.net","threadId":"2657","inReplyTo":"20051123025001.15527.qmail@web31812.mail.mud.yahoo.com","subject":"Re: Problem merging","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-23T03:06:03Z","receivedAt":"2005-11-23T03:06:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> Trying to merge 4b4a27dff4e2d4cc2eac1cde31aede834a966a48 into\n> e1ef47b54d7e7e477f7f1eb3251a9d37f38e0469 using 989e4d6cbc69191c41ddf4b1c492457410376b43.\n> Simple merge failed, trying Automatic merge\n> Removing include/asm-um/ldt.h\n> fatal: merge program failed\n> Automatic merge failed, fix up by hand\n>\n> This is with git HEAD: \n> 2392ee98eb76aa821de53c93c9e36acb18d27fc0 -- latest as\n> of now.\n>\n> Is this a bug in git? Since this process has always worked\n> before.\n\nAs \"Merging two branches\" section in Documentation/tutorial.txt\nshows, it is one of the valid outcome from merge to leave\nconflicts and have you manually resolve. So this process\nprobably is working correctly for you this time as well.\n\nSorry, but I am not a good enough cryptoanalyst to reverse SHA1\nhashes, and I cannot tell if the merge you did *should* have\nresulted in the conflict or not, just by looking at the three\ncommit object IDs.\n\nWhat does \"git diff\" and \"git diff HEAD\" tell you after the\nmerge procedure leaves conflict in the working tree (branchB\ndirectory, I mean)?\n"},{"id":"12590","messageId":"20051123034140.29993.qmail@web31801.mail.mud.yahoo.com","threadId":"2657","inReplyTo":"7v4q6483ms.fsf@assigned-by-dhcp.cox.net","subject":"Re: Problem merging","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2005-11-23T03:41:40Z","receivedAt":"2005-11-23T03:41:40Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n\n> What does \"git diff\" and \"git diff HEAD\" tell you after the\n> merge procedure leaves conflict in the working tree (branchB\n> directory, I mean)?\n\nApparently include/asm-um/ldt.h has been renamed\nand this was giving problems.\n\nI had to manually git-update-index --force-remove that\nfile and then git resolve worked ok.\n\n Luben\n"},{"id":"12604","messageId":"20051123085953.GA4933@c165.ib.student.liu.se","threadId":"2657","inReplyTo":"20051123025001.15527.qmail@web31812.mail.mud.yahoo.com","subject":"Re: Problem merging","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2005-11-23T08:59:53Z","receivedAt":"2005-11-23T08:59:53Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Tue, Nov 22, 2005 at 06:50:01PM -0800, Luben Tuikov wrote:\n> Ok, background:\n> \n> I've two branches of the same .git, _but_ they live in\n> different directories (bearing the branches' names)\n> with different index caches, but with the same identical\n> objects directory (different HEADs of course).\n> (in effect, I have both branches \"checked out\")\n> \n> Branch A is the \"trunk\", branch B is trunk+my changes.\n> I do:\n> \n> branchA: git pull \n> branchA: cd ../branchB/\n> branchB: git resolve HEAD branchA \"merge trunk\"\n> \n> And I get:\n> \n> Trying to merge 4b4a27dff4e2d4cc2eac1cde31aede834a966a48 into\n> e1ef47b54d7e7e477f7f1eb3251a9d37f38e0469 using 989e4d6cbc69191c41ddf4b1c492457410376b43.\n> Simple merge failed, trying Automatic merge\n> Removing include/asm-um/ldt.h\n> fatal: merge program failed\n> Automatic merge failed, fix up by hand\n> \n> This is with git HEAD: \n> 2392ee98eb76aa821de53c93c9e36acb18d27fc0 -- latest as\n> of now.\n> \n> Is this a bug in git? Since this process has always worked\n> before.\n\nHave you tried this merge with the recursive merge strategy?\n\nBtw is there a reason why 'recursive' isn't the default merge strategy\nfor git-merge? It might be a bit confusing that git-pull and git-merge\nhave different default strategies...\n\n- Fredrik\n"},{"id":"12620","messageId":"Pine.LNX.4.63.0511231546330.8191@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2657","inReplyTo":"7v4q6483ms.fsf@assigned-by-dhcp.cox.net","subject":"Re: Problem merging","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-23T14:49:06Z","receivedAt":"2005-11-23T14:49:06Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Nov 2005, Junio C Hamano wrote:\n\n> Sorry, but I am not a good enough cryptoanalyst to reverse SHA1\n> hashes,\n\nI think nobody is. Since there are infinitely many files having the same \nSHA1 (pigeon-hole principle), there probably are infinitely many of them \nwhich compile just fine (and therefore could be the original).\n\nNow, I tried to find all of them, but I, too, failed ;-)\n\nCiao,\nDscho\n"},{"id":"12636","messageId":"7vsltn403f.fsf@assigned-by-dhcp.cox.net","threadId":"2657","inReplyTo":"20051123085953.GA4933@c165.ib.student.liu.se","subject":"Re: Problem merging","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-23T19:48:20Z","receivedAt":"2005-11-23T19:48:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Kuivinen writes:\n\n> Have you tried this merge with the recursive merge strategy?\n>\n> Btw is there a reason why 'recursive' isn't the default merge strategy\n> for git-merge? It might be a bit confusing that git-pull and git-merge\n> have different default strategies...\n\nAgreed; will patch.\n"},{"id":"12711","messageId":"D8B7EF65-9D0C-4706-B248-4B7C118C16BF@hawaga.org.uk","threadId":"2657","inReplyTo":"Pine.LNX.4.63.0511231546330.8191@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Problem merging","fromName":"Ben Clifford","fromEmail":"benc@hawaga.org.uk","sentAt":"2005-11-24T10:54:41Z","receivedAt":"2005-11-24T10:54:41Z","isPatch":false,"sender":{"key":"benc@hawaga.org.uk","avatar":"https://gravatar.com/avatar/c7ce083471287f8e77b69dd147f757799d1efdd740727fd7e3003f33e88be898?d=mp&s=160"},"body":"On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:\n\n>\n> I think nobody is. Since there are infinitely many files having the \n> same\n> SHA1 (pigeon-hole principle),\n>\n\nhmm... pigeon-hole principle is just that there exists two files that \nhave the same SHA-1 as each other... doesn't say anything about *all* \nSHA-1s, though?\n\n-- \nBen • ベン • Бэн • 벤 • 班明\nhttp://www.hawaga.org.uk/ben/\nMy email is high latency but best way to contact me. Alternatively, \nSMS number(s) at above URL.\n"},{"id":"12714","messageId":"Pine.LNX.4.63.0511250208500.28437@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2657","inReplyTo":"D8B7EF65-9D0C-4706-B248-4B7C118C16BF@hawaga.org.uk","subject":"Re: Problem merging","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-25T01:13:54Z","receivedAt":"2005-11-25T01:13:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 24 Nov 2005, Ben Clifford wrote:\n\n> On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:\n> \n> > I think nobody is. Since there are infinitely many files having the same\n> > SHA1 (pigeon-hole principle),\n> \n> hmm... pigeon-hole principle is just that there exists two files that \n> have the same SHA-1 as each other... doesn't say anything about *all* \n> SHA-1s, though?\n\nOkay, the second part of the truth is: It would be a lousy cryptographic \nhash (which it isn't), if the SHA1s were not uniformly distributed over \nthe possible data.\n\nYou actually can be reasonably sure that given the SHA1s of all messages \nof length up to N (N being an integer at least the number of bits of the \nhash, i.e. 160 for SHA1), the counts of the different SHA1s should be \nequal.\n\nCiao,\nDscho\n"},{"id":"12715","messageId":"43866A51.4070109@op5.se","threadId":"2657","inReplyTo":"D8B7EF65-9D0C-4706-B248-4B7C118C16BF@hawaga.org.uk","subject":"Re: Problem merging","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-25T01:35:13Z","receivedAt":"2005-11-25T01:35:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Ben Clifford wrote:\n> hmm... pigeon-hole principle is just that there exists two files that \n> have the same SHA-1 as each other... doesn't say anything about *all* \n> SHA-1s, though?\n> \n\nIt doesn't have to say that explicitly. It's universally applicable to \nall static-size checksum algorithms given an infinite amount of inputs.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"12818","messageId":"438A241C.5010007@zytor.com","threadId":"2657","inReplyTo":"D8B7EF65-9D0C-4706-B248-4B7C118C16BF@hawaga.org.uk","subject":"Re: Problem merging","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-11-27T21:24:44Z","receivedAt":"2005-11-27T21:24:44Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Ben Clifford wrote:\n> On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:\n> \n>>\n>> I think nobody is. Since there are infinitely many files having the same\n>> SHA1 (pigeon-hole principle),\n> \n> hmm... pigeon-hole principle is just that there exists two files that \n> have the same SHA-1 as each other... doesn't say anything about *all* \n> SHA-1s, though?\n> \n\nThere are an infinite number of possible files (specifically, \naleph-null.) There are a finite number of possible SHA-1's \n(specifically, 1461501637330902918203684832716283019655932542976.) \nTherefore the pidgeon-hole principle tells you there must be at least \none SHA-1 value that hashes an infinite number of files (aleph-null, again.)\n\nGiven that SHA-1 is believed to be uniformly distributed, it's quite \nlikely *ALL* SHA-1's hash an infinite number of files, but the \npigeon-hole principle can't tell you that.\n\n\t-hpa\n"}]}