{"thread":{"id":"26498","subject":"libreoffice merge issue ...","startedAt":"2011-02-14T16:07:15Z","lastAt":"2011-04-29T12:55:05Z","messageCount":10,"participants":["Michael Meeks","Norbert Thiebaud","Ferry Huberts","Jeff King","Junio C Hamano","Damien Wyart"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161069","messageId":"1297699635.31477.253.camel@lenovo-w500","threadId":"26498","inReplyTo":null,"subject":"libreoffice merge issue ...","fromName":"Michael Meeks","fromEmail":"michael.meeks@novell.com","sentAt":"2011-02-14T16:07:15Z","receivedAt":"2011-02-14T16:07:15Z","isPatch":false,"sender":{"key":"michael.meeks@novell.com","avatar":null},"body":"Hi guys,\n\nWe are having quite some fun merging git branches with LibreOffice, and\nI stumbled over this just now with master git with hash:\n00e6ee724640701b32aca27cc930fd6409c87ae2\n\nSetup (some large repos):\n\n\tgit clone git://anongit.freedesktop.org/libreoffice/libs-core\n\tgit checkout integration/dev300_m98\n\tgit remote add stage git://anongit.freedesktop.org/libreoffice/staging/@REPO@\n\tgit fetch stage\n\n\tTest[1]:\n\n\tgit merge stage/premerge/dev300_m98\n\tgit diff idl/source/cmptools/lex.cxx\n\n\tyields:\n\n@@@ -147,11 -147,7 +147,15 @@@ SvToken & SvToken::operator = ( const S\n *************************************************************************/\n void SvTokenStream::InitCtor()\n {\n++<<<<<<< HEAD\n +#ifdef DOS\n + SetCharSet( CHARSET_ANSI );\n +#else\n SetCharSet( gsl_getSystemTextEncoding() );\n +#endif\n++=======\n++ SetCharSet( gsl_getSystemTextEncoding() );\n++>>>>>>> stage/premerge/dev300_m98\n aStrTrue = \"TRUE\";\n aStrFalse = \"FALSE\";\n nLine = nColumn = 0;\n\n\tWith the above master hash; whereas with v1.7.3.4 it yields nothing (as\nit should IMHO) - we havn't edited things around that chunk in master.\n\n\tThat is slightly concerning; thoughts much appreciated. Incidentally,\nthe whole 'make install' installs into ~/bin was extremely unexpected\nand yielded 30minutes of pain trying to work out what was installed\nwhere and why, and the interaction with --prefix, and ... now it seems I\nshould always run rehash; git --version before any command, and sanity\ncheck things ;-)\n\n\tThanks,\n\n\t\tMichael.\n\n[1] - potentially you need:\n[merge]\n renamelimit = 20000\nin your ~/.gitconfig\n-- \n michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot\n"},{"id":"161071","messageId":"AANLkTik9icGApTP+0C+ANWsLZBb8HVTXo-cyW3kKEppw@mail.gmail.com","threadId":"26498","inReplyTo":"1297699635.31477.253.camel@lenovo-w500","subject":"Re: libreoffice merge issue ...","fromName":"Norbert Thiebaud","fromEmail":"nthiebaud@gmail.com","sentAt":"2011-02-14T16:52:26Z","receivedAt":"2011-02-14T16:52:26Z","isPatch":false,"sender":{"key":"nthiebaud@gmail.com","avatar":null},"body":"On Mon, Feb 14, 2011 at 10:07 AM, Michael Meeks\n wrote:\n> Hi guys,\n>\n> We are having quite some fun merging git branches with LibreOffice, and\n> I stumbled over this just now with master git with hash:\n> 00e6ee724640701b32aca27cc930fd6409c87ae2\n>\n> Setup (some large repos):\n>\n>        git clone git://anongit.freedesktop.org/libreoffice/libs-core\n>        git checkout integration/dev300_m98\n>        git remote add stage git://anongit.freedesktop.org/libreoffice/staging/@REPO@\n\ncorrection: this should read\n git remote add stage\ngit://anongit.freedesktop.org/libreoffice/staging/libs-core\n\nor you should use ./g instead of git for all these 3 git operations\n\nNorbert\n\n\n>        git fetch stage\n>\n>        Test[1]:\n>\n>        git merge stage/premerge/dev300_m98\n>        git diff idl/source/cmptools/lex.cxx\n>\n>        yields:\n>\n> @@@ -147,11 -147,7 +147,15 @@@ SvToken & SvToken::operator = ( const S\n>  *************************************************************************/\n>  void SvTokenStream::InitCtor()\n>  {\n> ++<<<<<<< HEAD\n>  +#ifdef DOS\n>  +    SetCharSet( CHARSET_ANSI );\n>  +#else\n>      SetCharSet( gsl_getSystemTextEncoding() );\n>  +#endif\n> ++=======\n> ++    SetCharSet( gsl_getSystemTextEncoding() );\n> ++>>>>>>> stage/premerge/dev300_m98\n>      aStrTrue  = \"TRUE\";\n>      aStrFalse = \"FALSE\";\n>      nLine       = nColumn = 0;\n>\n>        With the above master hash; whereas with v1.7.3.4 it yields nothing (as\n> it should IMHO) - we havn't edited things around that chunk in master.\n>\n>        That is slightly concerning; thoughts much appreciated. Incidentally,\n> the whole 'make install' installs into ~/bin was extremely unexpected\n> and yielded 30minutes of pain trying to work out what was installed\n> where and why, and the interaction with --prefix, and ... now it seems I\n> should always run rehash; git --version before any command, and sanity\n> check things ;-)\n>\n>        Thanks,\n>\n>                Michael.\n>\n> [1] - potentially you need:\n> [merge]\n>    renamelimit = 20000\n> in your ~/.gitconfig\n> --\n>  michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot\n>\n>\n>\n"},{"id":"161078","messageId":"4D5965CC.4030706@hupie.com","threadId":"26498","inReplyTo":"1297699635.31477.253.camel@lenovo-w500","subject":"Re: libreoffice merge issue ...","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-02-14T17:26:36Z","receivedAt":"2011-02-14T17:26:36Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"\n\nOn 02/14/2011 05:07 PM, Michael Meeks wrote:\n> Hi guys,\n> \n> We are having quite some fun merging git branches with LibreOffice, and\n> I stumbled over this just now with master git with hash:\n> 00e6ee724640701b32aca27cc930fd6409c87ae2\n> \n> Setup (some large repos):\n> \n> \tgit clone git://anongit.freedesktop.org/libreoffice/libs-core\n> \tgit checkout integration/dev300_m98\n> \tgit remote add stage git://anongit.freedesktop.org/libreoffice/staging/@REPO@\n> \tgit fetch stage\n> \n> \tTest[1]:\n> \n> \tgit merge stage/premerge/dev300_m98\n\nthe merge has detected a conflict and has annotated the conflicted\nfile(s). at least one of the conflicting files is\nidl/source/cmptools/lex.cxx (you might want to do 'git mergetool' after\nyou have setup your merge tool)\n\n> \tgit diff idl/source/cmptools/lex.cxx\n> \n\nyou're diffing the 'unmerged, annotated' file against the original file\nbefore the merge.\n\nyour merge is not yet complete, you'll have to resolve the conflicts first\nand then commit\n\n\n> \tyields:\n> \n> @@@ -147,11 -147,7 +147,15 @@@ SvToken & SvToken::operator = ( const S\n> *************************************************************************/\n> void SvTokenStream::InitCtor()\n> {\n> ++<<<<<<< HEAD\n> +#ifdef DOS\n> + SetCharSet( CHARSET_ANSI );\n> +#else\n> SetCharSet( gsl_getSystemTextEncoding() );\n> +#endif\n> ++=======\n> ++ SetCharSet( gsl_getSystemTextEncoding() );\n> ++>>>>>>> stage/premerge/dev300_m98\n\n\nthis is the annotation of the conflict\n\ngrtz\n\n-- \nFerry Huberts\n"},{"id":"161077","messageId":"AANLkTi=SVDBgVYZpPUrCnKZyAaos=VKCLTvP4Bm7_Mk0@mail.gmail.com","threadId":"26498","inReplyTo":"4D5965CC.4030706@hupie.com","subject":"Re: libreoffice merge issue ...","fromName":"Norbert Thiebaud","fromEmail":"nthiebaud@gmail.com","sentAt":"2011-02-14T17:33:24Z","receivedAt":"2011-02-14T17:33:24Z","isPatch":false,"sender":{"key":"nthiebaud@gmail.com","avatar":null},"body":"On Mon, Feb 14, 2011 at 11:26 AM, Ferry Huberts wrote:\n>\n>\n> On 02/14/2011 05:07 PM, Michael Meeks wrote:\n>> Hi guys,\n>>\n>> We are having quite some fun merging git branches with LibreOffice, and\n>> I stumbled over this just now with master git with hash:\n>> 00e6ee724640701b32aca27cc930fd6409c87ae2\n>>\n[...]\n>>       yields:\n>>\n>> @@@ -147,11 -147,7 +147,15 @@@ SvToken & SvToken::operator = ( const S\n>>   *************************************************************************/\n>>   void SvTokenStream::InitCtor()\n>>   {\n>> ++<<<<<<< HEAD\n>>  +#ifdef DOS\n>>  +    SetCharSet( CHARSET_ANSI );\n>>  +#else\n>>       SetCharSet( gsl_getSystemTextEncoding() );\n>>  +#endif\n>> ++=======\n>> ++    SetCharSet( gsl_getSystemTextEncoding() );\n>> ++>>>>>>> stage/premerge/dev300_m98\n>\n>\n> this is the annotation of the conflict\n\nThe point is that there should not have been a conflict to start with.\ngit 1.7.3.4 agree that there is no conflict.\n\nNorbert\n\n>\n> grtz\n>\n> --\n> Ferry Huberts\n>\n"},{"id":"161170","messageId":"20110215094546.GA25530@sigill.intra.peff.net","threadId":"26498","inReplyTo":"1297699635.31477.253.camel@lenovo-w500","subject":"Re: libreoffice merge issue ...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-15T09:45:46Z","receivedAt":"2011-02-15T09:45:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 14, 2011 at 04:07:15PM +0000, Michael Meeks wrote:\n\n> Setup (some large repos):\n> \n> \tgit clone git://anongit.freedesktop.org/libreoffice/libs-core\n> \tgit checkout integration/dev300_m98\n> \tgit remote add stage git://anongit.freedesktop.org/libreoffice/staging/@REPO@\n> \tgit fetch stage\n> \n> \tTest[1]:\n> \n> \tgit merge stage/premerge/dev300_m98\n> \tgit diff idl/source/cmptools/lex.cxx\n> \n> \tyields:\n> [a conflict in idl/source/cmptools/lex.cxx]\n> \n> \tWith the above master hash; whereas with v1.7.3.4 it yields nothing (as\n> it should IMHO) - we havn't edited things around that chunk in master.\n\nInteresting. I looked at both sides of the merge and the merge base, and\nthere definitely should not be a conflict there. The regression bisects\nto 83c9031 (unpack_trees(): skip trees that are the same in all input,\n2010-12-22). Reverting that commit makes the problem go away.\n\n-Peff\n"},{"id":"161201","messageId":"7vaahxp250.fsf@alter.siamese.dyndns.org","threadId":"26498","inReplyTo":"20110215094546.GA25530@sigill.intra.peff.net","subject":"Re: libreoffice merge issue ...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-15T18:46:03Z","receivedAt":"2011-02-15T18:46:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Interesting. I looked at both sides of the merge and the merge base, and\n> there definitely should not be a conflict there. The regression bisects\n> to 83c9031 (unpack_trees(): skip trees that are the same in all input,\n> 2010-12-22). Reverting that commit makes the problem go away.\n\nThanks; I was wondering about this myself but you bisected it faster.\n\nWill revert.\n"},{"id":"161253","messageId":"20110216025726.GC7085@sigill.intra.peff.net","threadId":"26498","inReplyTo":"7vaahxp250.fsf@alter.siamese.dyndns.org","subject":"Re: libreoffice merge issue ...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-02-16T02:57:27Z","receivedAt":"2011-02-16T02:57:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 15, 2011 at 10:46:03AM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Interesting. I looked at both sides of the merge and the merge base, and\n> > there definitely should not be a conflict there. The regression bisects\n> > to 83c9031 (unpack_trees(): skip trees that are the same in all input,\n> > 2010-12-22). Reverting that commit makes the problem go away.\n> \n> Thanks; I was wondering about this myself but you bisected it faster.\n> \n> Will revert.\n\nOne other thing I noticed during the bisect: when using a version of git\ncontaining 83c9031, the merge took a lot longer. As in, 13 seconds with\nv1.7.3 versus 69 seconds with master.\n\nThat may simply be because the bug being demonstrated causes us to\nerroneously do more file-level merging than we would otherwise need to.\nBut I thought it worth mentioning in case you want to delve into fixing\nthe code.\n\n-Peff\n"},{"id":"161339","messageId":"7vfwrnis50.fsf@alter.siamese.dyndns.org","threadId":"26498","inReplyTo":"20110216025726.GC7085@sigill.intra.peff.net","subject":"Re: libreoffice merge issue ...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-16T21:30:51Z","receivedAt":"2011-02-16T21:30:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> Thanks; I was wondering about this myself but you bisected it faster.\n>> \n>> Will revert.\n>\n> One other thing I noticed during the bisect: when using a version of git\n> containing 83c9031, the merge took a lot longer. As in, 13 seconds with\n> v1.7.3 versus 69 seconds with master.\n>\n> That may simply be because the bug being demonstrated causes us to\n> erroneously do more file-level merging than we would otherwise need to.\n\nYeah, the reverted 83c9031 (unpack_trees(): skip trees that are the same\nin all input, 2010-12-22) also seems to have seriously broken intermediate\nmerge merge-recursive makes. I actually recall scratching my head when I\nmade 00e6ee7 (Merge branch 'maint', 2011-02-11) that was causing add/add\nconflict when it shouldn't. It turns out that quite a lot of entries were\nmissing in contrib/ area from the virtual common ancestry tree synthesized\nby merge-recursive that called into the botched unpack_trees()---it of\ncourse would result in add/add conflict if a merge is done using such a\ntree as the common.\n\nNo, I haven't had a chance nor energy to dig further than what I reported\nabove.\n"},{"id":"166193","messageId":"20110421140132.GA6696@brouette","threadId":"26498","inReplyTo":"7vfwrnis50.fsf@alter.siamese.dyndns.org","subject":"Re: libreoffice merge issue ...","fromName":"Damien Wyart","fromEmail":"damien.wyart@gmail.com","sentAt":"2011-04-21T14:01:32Z","receivedAt":"2011-04-21T14:01:32Z","isPatch":false,"sender":{"key":"damien.wyart@gmail.com","avatar":null},"body":"Hi,\n\nSorry to wake up an old thread.\n\n* Junio C Hamano [2011-02-16 13:30]:\n> Yeah, the reverted 83c9031 (unpack_trees(): skip trees that are the\n> same in all input, 2010-12-22) also seems to have seriously broken\n> intermediate merge merge-recursive makes. I actually recall scratching\n> my head when I made 00e6ee7 (Merge branch 'maint', 2011-02-11) that\n> was causing add/add conflict when it shouldn't. It turns out that\n> quite a lot of entries were missing in contrib/ area from the virtual\n> common ancestry tree synthesized by merge-recursive that called into\n> the botched unpack_trees()---it of course would result in add/add\n> conflict if a merge is done using such a tree as the common.\n\n> No, I haven't had a chance nor energy to dig further than what\n> I reported above.\n\nOut of curiosity, I would like to know if digging further into this\nissue is still on your TODO list. I feel understanding exactly what was\nwrong in 83c9031 would be interesting ; having just the revert is a bit\nfrustrating.\n\nThe initial optimization in 83c9031 seemed right at first glance, so\nI would be interesting in having a more final answer to this.\n\n\nMany thanks in advance,\n-- \nDamien Wyart\n"},{"id":"166733","messageId":"20110429125505.GA4540@sigill.intra.peff.net","threadId":"26498","inReplyTo":"20110421140132.GA6696@brouette","subject":"Re: libreoffice merge issue ...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-29T12:55:05Z","receivedAt":"2011-04-29T12:55:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 21, 2011 at 04:01:32PM +0200, Damien Wyart wrote:\n\n> * Junio C Hamano [2011-02-16 13:30]:\n> > Yeah, the reverted 83c9031 (unpack_trees(): skip trees that are the\n> > same in all input, 2010-12-22) also seems to have seriously broken\n> > intermediate merge merge-recursive makes. I actually recall scratching\n> > my head when I made 00e6ee7 (Merge branch 'maint', 2011-02-11) that\n> > was causing add/add conflict when it shouldn't. It turns out that\n> > quite a lot of entries were missing in contrib/ area from the virtual\n> > common ancestry tree synthesized by merge-recursive that called into\n> > the botched unpack_trees()---it of course would result in add/add\n> > conflict if a merge is done using such a tree as the common.\n> \n> > No, I haven't had a chance nor energy to dig further than what\n> > I reported above.\n> \n> Out of curiosity, I would like to know if digging further into this\n> issue is still on your TODO list. I feel understanding exactly what was\n> wrong in 83c9031 would be interesting ; having just the revert is a bit\n> frustrating.\n> \n> The initial optimization in 83c9031 seemed right at first glance, so\n> I would be interesting in having a more final answer to this.\n\nI didn't dig further, but looking at 83c9031 with a fresh set of eyes, I\nthink that merge-recursive falls under the \"exceptions\" that Junio\nlisted in the commit message. That is, he indicates correctly that we\ncannot use this optimization for \"reset --hard\" or for checking out for\nthe first time.\n\nSimilarly, merge-recursive is going to do many 3-way merges between\ntrees into an empty index (when merging virtual ancestors), and we need\nto unpack those subtrees even if they are all the same. But given the\nconditions added by 83c9031 in unpack-trees.c:fast_forward_merge, I\ndon't see anything preventing the optimization in how merge-recursive\ncalls into unpack-trees.\n\nWe do a discard_cache() right before doing the 3-way merge for virtual\nancestors. So we will see that there are no entries in our current index\nfor that directory. That may be a clue that the optimization should not\nbe used.\n\n-Peff\n"}]}