{"thread":{"id":"44988","subject":"show all merge conflicts","startedAt":"2017-01-27T17:28:07Z","lastAt":"2017-02-27T21:13:04Z","messageCount":9,"participants":["Michael Spiegel","Jeff King","G. Sylvie Davies","Philip Oakley","Michael J Gruber","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310412","messageId":"CANwu5-o=3p8QfWo9wQvok=UZESRVtF3Uxb3nEMZVv8AvkKYYGw@mail.gmail.com","threadId":"44988","inReplyTo":null,"subject":"show all merge conflicts","fromName":"Michael Spiegel","fromEmail":"michael.m.spiegel@gmail.com","sentAt":"2017-01-27T16:56:08Z","receivedAt":"2017-01-27T17:28:07Z","isPatch":false,"sender":{"key":"michael.m.spiegel@gmail.com","avatar":null},"body":"Hi folks,\n\nI'm trying to determine whether a merge required a conflict to resolve\nafter the merge has occurred. The git book has some advice\n(https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging) to use\n`git show` on the merge commit or use `git log --cc -p -1`. These\nstrategies work when the merge conflict was resolved with a change\nthat is different from either parent. When the conflict is resolved\nwith a change that is the same as one of the parents, then these\ncommands are indistinguishable from a merge that did not conflict. Is\nit possible to distinguish between a conflict-free merge and a merge\nconflict that is resolved by with the changes from one the parents?\n\nThanks,\n--Michael\n"},{"id":"310420","messageId":"20170127175151.srhhczliqgvbzcre@sigill.intra.peff.net","threadId":"44988","inReplyTo":"CANwu5-o=3p8QfWo9wQvok=UZESRVtF3Uxb3nEMZVv8AvkKYYGw@mail.gmail.com","subject":"Re: show all merge conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-27T17:51:51Z","receivedAt":"2017-01-27T17:54:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 27, 2017 at 11:56:08AM -0500, Michael Spiegel wrote:\n\n> I'm trying to determine whether a merge required a conflict to resolve\n> after the merge has occurred. The git book has some advice\n> (https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging) to use\n> `git show` on the merge commit or use `git log --cc -p -1`. These\n> strategies work when the merge conflict was resolved with a change\n> that is different from either parent. When the conflict is resolved\n> with a change that is the same as one of the parents, then these\n> commands are indistinguishable from a merge that did not conflict. Is\n> it possible to distinguish between a conflict-free merge and a merge\n> conflict that is resolved by with the changes from one the parents?\n\nNo. You'd have to replay the merge to know if it would have had\nconflicts.\n\nThere was a patch series a few years ago that added a new diff-mode to\ndo exactly that, and show the diff against what was resolved. It had a\nfew issues (I don't remember exactly what) and never got merged.\n\nCertainly one complication is that you don't know exactly _how_ the\nmerge was done in the first place (e.g., which merge strategy, which\ncustom merge drivers were in effect, etc). But in general, replaying\nwith a standard merge-recursive would get you most of what you want to\nknow.\n\nI've done this manually sometimes when digging into erroneous merges\n(e.g., somebody accidentally runs \"git reset -- <paths>\" in the middle\nof a merge and throws away some changes.\n\nYou should be able to do:\n\n  git checkout $merge^1\n  git merge $merge^2\n  git diff -R $merge\n\nto see what the original resolution did.\n\n-Peff\n"},{"id":"310487","messageId":"CAAj3zPzO4+9t9_L2OXFmkihw-HwFvzybb7GXs4tTeFRyZHOaNQ@mail.gmail.com","threadId":"44988","inReplyTo":"20170127175151.srhhczliqgvbzcre@sigill.intra.peff.net","subject":"Re: show all merge conflicts","fromName":"G. Sylvie Davies","fromEmail":"sylvie@bit-booster.com","sentAt":"2017-01-28T05:42:41Z","receivedAt":"2017-01-28T05:44:05Z","isPatch":false,"sender":{"key":"sylvie@bit-booster.com","avatar":"https://gravatar.com/avatar/eb5bda7d3fb1e3361252bbf100d1f355ffe9ff8d8b559a08e4c7bc17d6f949d5?d=mp&s=160"},"body":"On Fri, Jan 27, 2017 at 9:51 AM, Jeff King <peff@peff.net> wrote:\n> On Fri, Jan 27, 2017 at 11:56:08AM -0500, Michael Spiegel wrote:\n>\n>> I'm trying to determine whether a merge required a conflict to resolve\n>> after the merge has occurred. The git book has some advice\n>> (https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging) to use\n>> `git show` on the merge commit or use `git log --cc -p -1`. These\n>> strategies work when the merge conflict was resolved with a change\n>> that is different from either parent. When the conflict is resolved\n>> with a change that is the same as one of the parents, then these\n>> commands are indistinguishable from a merge that did not conflict. Is\n>> it possible to distinguish between a conflict-free merge and a merge\n>> conflict that is resolved by with the changes from one the parents?\n>\n> No. You'd have to replay the merge to know if it would have had\n> conflicts.\n>\n\n\nAside from the usual \"git log -cc\", I think this should work (replace\nHEAD with whichever commit you are analyzing):\n\ngit diff --name-only HEAD^2...HEAD^1 > m1\ngit diff --name-only HEAD^1...HEAD^2 > b1\ngit diff --name-only HEAD^1..HEAD    > m2\ngit diff --name-only HEAD^2..HEAD    > b2\n\nIf files listed between m1 and b2 differ, then the merge is dirty.\nSimilarly for m2 and b1.\n\nMore information here:\n\nhttp://stackoverflow.com/questions/27683077/how-do-you-detect-an-evil-merge-in-git/41356308#41356308\n\n\n- Sylvie\n\n\n\n> There was a patch series a few years ago that added a new diff-mode to\n> do exactly that, and show the diff against what was resolved. It had a\n> few issues (I don't remember exactly what) and never got merged.\n>\n> Certainly one complication is that you don't know exactly _how_ the\n> merge was done in the first place (e.g., which merge strategy, which\n> custom merge drivers were in effect, etc). But in general, replaying\n> with a standard merge-recursive would get you most of what you want to\n> know.\n>\n> I've done this manually sometimes when digging into erroneous merges\n> (e.g., somebody accidentally runs \"git reset -- <paths>\" in the middle\n> of a merge and throws away some changes.\n>\n> You should be able to do:\n>\n>   git checkout $merge^1\n>   git merge $merge^2\n>   git diff -R $merge\n>\n> to see what the original resolution did.\n>\n> -Peff\n"},{"id":"310488","messageId":"C0FB9362D83842EB97B4C795C91F1775@PhilipOakley","threadId":"44988","inReplyTo":"CAAj3zPzO4+9t9_L2OXFmkihw-HwFvzybb7GXs4tTeFRyZHOaNQ@mail.gmail.com","subject":"Re: show all merge conflicts","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-28T13:48:00Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"G. Sylvie Davies\" <sylvie@bit-booster.com>\n> On Fri, Jan 27, 2017 at 9:51 AM, Jeff King <peff@peff.net> wrote:\n>> On Fri, Jan 27, 2017 at 11:56:08AM -0500, Michael Spiegel wrote:\n>>\n>>> I'm trying to determine whether a merge required a conflict to resolve\n>>> after the merge has occurred. The git book has some advice\n>>> (https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging) to use\n>>> `git show` on the merge commit or use `git log --cc -p -1`. These\n>>> strategies work when the merge conflict was resolved with a change\n>>> that is different from either parent. When the conflict is resolved\n>>> with a change that is the same as one of the parents, then these\n>>> commands are indistinguishable from a merge that did not conflict. Is\n>>> it possible to distinguish between a conflict-free merge and a merge\n>>> conflict that is resolved by with the changes from one the parents?\n>>\n>> No. You'd have to replay the merge to know if it would have had\n>> conflicts.\n>>\n>\n>\n> Aside from the usual \"git log -cc\", I think this should work (replace\n> HEAD with whichever commit you are analyzing):\n>\n> git diff --name-only HEAD^2...HEAD^1 > m1\n> git diff --name-only HEAD^1...HEAD^2 > b1\n> git diff --name-only HEAD^1..HEAD    > m2\n> git diff --name-only HEAD^2..HEAD    > b2\n>\n> If files listed between m1 and b2 differ, then the merge is dirty.\n> Similarly for m2 and b1.\n>\n> More information here:\n>\n> http://stackoverflow.com/questions/27683077/how-do-you-detect-an-evil-merge-in-git/41356308#41356308\n>\n>\n> - Sylvie\n\nThis feels as though there ought to be some sort of --left-right option to \nget an indication of which side various changes came from\n\n>\n>> There was a patch series a few years ago that added a new diff-mode to\n>> do exactly that, and show the diff against what was resolved. It had a\n>> few issues (I don't remember exactly what) and never got merged.\n>>\n>> Certainly one complication is that you don't know exactly _how_ the\n>> merge was done in the first place (e.g., which merge strategy, which\n>> custom merge drivers were in effect, etc). But in general, replaying\n>> with a standard merge-recursive would get you most of what you want to\n>> know.\n>>\n>> I've done this manually sometimes when digging into erroneous merges\n>> (e.g., somebody accidentally runs \"git reset -- <paths>\" in the middle\n>> of a merge and throws away some changes.\n>>\n>> You should be able to do:\n>>\n>>   git checkout $merge^1\n>>   git merge $merge^2\n>>   git diff -R $merge\n>>\n>> to see what the original resolution did.\n>>\n>> -Peff\n> \n\n"},{"id":"310489","messageId":"20170128142808.hefnv7r3h6zidobw@sigill.intra.peff.net","threadId":"44988","inReplyTo":"CAAj3zPzO4+9t9_L2OXFmkihw-HwFvzybb7GXs4tTeFRyZHOaNQ@mail.gmail.com","subject":"Re: show all merge conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-28T14:28:08Z","receivedAt":"2017-01-28T14:28:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 27, 2017 at 09:42:41PM -0800, G. Sylvie Davies wrote:\n\n> Aside from the usual \"git log -cc\", I think this should work (replace\n> HEAD with whichever commit you are analyzing):\n> \n> git diff --name-only HEAD^2...HEAD^1 > m1\n> git diff --name-only HEAD^1...HEAD^2 > b1\n> git diff --name-only HEAD^1..HEAD    > m2\n> git diff --name-only HEAD^2..HEAD    > b2\n> \n> If files listed between m1 and b2 differ, then the merge is dirty.\n> Similarly for m2 and b1.\n> \n> More information here:\n> \n> http://stackoverflow.com/questions/27683077/how-do-you-detect-an-evil-merge-in-git/41356308#41356308\n\nI don't think that can reliably find evil merges, since it looks at the\nfile level. If you had one hunk resolved for \"theirs\" and one hunk for\n\"ours\" in a given file, then the file will be listed in each diff,\nwhether it has evil hunks or not.\n\nI don't think this is just about evil merges, though. For instance,\ntry:\n\n  seq 1 10 >file\n  git add file\n  git commit -m base\n\n  sed s/4/master/ <file >tmp && mv tmp file\n  git commit -am master\n\n  git checkout -b other HEAD^\n  sed s/4/other/ <file >tmp && mv tmp file\n  git commit -am other\n\n  git merge master\n  git checkout --ours file\n  git commit -am merged\n\n  merge=$(git rev-parse HEAD)\n\nThe question is: were there conflicts in $merge, and how were they\nresolved?\n\nThat isn't an evil merge, but there's still something interesting to\nshow that \"git log --cc\" won't display.\n\nReplaying the merge like:\n\n  git checkout $merge^1\n  git merge $merge^2\n  git diff -R $merge\n\nshows you the patch to go from the conflict state to the final one.\n\n-Peff\n"},{"id":"310511","messageId":"CAAj3zPx5fKHUTLLEuuZjmq+H5somp980j0hqWjmLyvLuk709GQ@mail.gmail.com","threadId":"44988","inReplyTo":"20170128142808.hefnv7r3h6zidobw@sigill.intra.peff.net","subject":"Re: show all merge conflicts","fromName":"G. Sylvie Davies","fromEmail":"sylvie@bit-booster.com","sentAt":"2017-01-29T06:45:04Z","receivedAt":"2017-01-29T18:59:54Z","isPatch":false,"sender":{"key":"sylvie@bit-booster.com","avatar":"https://gravatar.com/avatar/eb5bda7d3fb1e3361252bbf100d1f355ffe9ff8d8b559a08e4c7bc17d6f949d5?d=mp&s=160"},"body":"On Sat, Jan 28, 2017 at 6:28 AM, Jeff King <peff@peff.net> wrote:\n> On Fri, Jan 27, 2017 at 09:42:41PM -0800, G. Sylvie Davies wrote:\n>\n>> Aside from the usual \"git log -cc\", I think this should work (replace\n>> HEAD with whichever commit you are analyzing):\n>>\n>> git diff --name-only HEAD^2...HEAD^1 > m1\n>> git diff --name-only HEAD^1...HEAD^2 > b1\n>> git diff --name-only HEAD^1..HEAD    > m2\n>> git diff --name-only HEAD^2..HEAD    > b2\n>>\n>> If files listed between m1 and b2 differ, then the merge is dirty.\n>> Similarly for m2 and b1.\n>>\n>> More information here:\n>>\n>> http://stackoverflow.com/questions/27683077/how-do-you-detect-an-evil-merge-in-git/41356308#41356308\n>\n> I don't think that can reliably find evil merges, since it looks at the\n> file level. If you had one hunk resolved for \"theirs\" and one hunk for\n> \"ours\" in a given file, then the file will be listed in each diff,\n> whether it has evil hunks or not.\n>\n\nWell, you have to do both.  Do \"git show -c\" to catch that one\n(\"theirs\" for one hunk, \"ours\" for the other, same file).\n\nAnd then do that sequence of the 4 \"git diff\" commands to identify\ndirty merges where \"theirs\" or \"ours\" was applied to entire files, and\nthus not showing up in the \"git show -c\".\n\n> I don't think this is just about evil merges, though. For instance,\n> try:\n>\n>   seq 1 10 >file\n>   git add file\n>   git commit -m base\n>\n>   sed s/4/master/ <file >tmp && mv tmp file\n>   git commit -am master\n>\n>   git checkout -b other HEAD^\n>   sed s/4/other/ <file >tmp && mv tmp file\n>   git commit -am other\n>\n>   git merge master\n>   git checkout --ours file\n>   git commit -am merged\n>\n>   merge=$(git rev-parse HEAD)\n>\n> The question is: were there conflicts in $merge, and how were they\n> resolved?\n>\n> That isn't an evil merge, but there's still something interesting to\n> show that \"git log --cc\" won't display.\n>\n> Replaying the merge like:\n>\n>   git checkout $merge^1\n>   git merge $merge^2\n>   git diff -R $merge\n>\n> shows you the patch to go from the conflict state to the final one.\n>\n\nI know the stackoverflow question asks \"how to detect evil merges\",\nand I go along with that in my answer.  But honestly I prefer to call\nthem dirty rather than evil, and by \"dirty\" I just mean merges that\ndid not resolve cleanly via \"git merge\", and had some form of user\nintervention, be it conflict resolution, or other strange things.\n\nThe trick I propose with the sequence of 4 \"git diff\" commands\nidentifies that merge from your example as dirty:\n\n$ cat b1 m2\nfile\n\n$ cat b2 m1\nfile\nfile\n\nThe trick doesn't really tell you much except that the merge is dirty.\nIf you notice that the \"m2\" file is empty, I think that's one way to\nrealize that master's edit was dropped, and therefore \"other\" won.\n\nMaybe it even merged cleanly but someone did a \"git commit --amend\" to\nmake it the merge dirty after the fact.\n\nI do like your approach, it's very simple and reliable.  But in my\nsituation I'm writing pre-receive hooks for bare repos, so I don't\nthink I can actually do \"git merge\"!\n\nI think my suggestion would work for OP, as long as they also run \"git\nshow -c\" alongside it.   (And your suggestion would work, too, of\ncourse).\n\n\n\n- Sylvie\n"},{"id":"312723","messageId":"6ff25254-720e-5b85-ba6d-22b16e91b354@drmicha.warpmail.net","threadId":"44988","inReplyTo":"CAAj3zPx5fKHUTLLEuuZjmq+H5somp980j0hqWjmLyvLuk709GQ@mail.gmail.com","subject":"Re: show all merge conflicts","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2017-02-27T14:28:32Z","receivedAt":"2017-02-27T14:28:40Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"G. Sylvie Davies venit, vidit, dixit 29.01.2017 07:45:\n> On Sat, Jan 28, 2017 at 6:28 AM, Jeff King <peff@peff.net> wrote:\n>> On Fri, Jan 27, 2017 at 09:42:41PM -0800, G. Sylvie Davies wrote:\n>>\n>>> Aside from the usual \"git log -cc\", I think this should work (replace\n>>> HEAD with whichever commit you are analyzing):\n>>>\n>>> git diff --name-only HEAD^2...HEAD^1 > m1\n>>> git diff --name-only HEAD^1...HEAD^2 > b1\n>>> git diff --name-only HEAD^1..HEAD    > m2\n>>> git diff --name-only HEAD^2..HEAD    > b2\n>>>\n>>> If files listed between m1 and b2 differ, then the merge is dirty.\n>>> Similarly for m2 and b1.\n>>>\n>>> More information here:\n>>>\n>>> http://stackoverflow.com/questions/27683077/how-do-you-detect-an-evil-merge-in-git/41356308#41356308\n>>\n>> I don't think that can reliably find evil merges, since it looks at the\n>> file level. If you had one hunk resolved for \"theirs\" and one hunk for\n>> \"ours\" in a given file, then the file will be listed in each diff,\n>> whether it has evil hunks or not.\n>>\n> \n> Well, you have to do both.  Do \"git show -c\" to catch that one\n> (\"theirs\" for one hunk, \"ours\" for the other, same file).\n> \n> And then do that sequence of the 4 \"git diff\" commands to identify\n> dirty merges where \"theirs\" or \"ours\" was applied to entire files, and\n> thus not showing up in the \"git show -c\".\n> \n>> I don't think this is just about evil merges, though. For instance,\n>> try:\n>>\n>>   seq 1 10 >file\n>>   git add file\n>>   git commit -m base\n>>\n>>   sed s/4/master/ <file >tmp && mv tmp file\n>>   git commit -am master\n>>\n>>   git checkout -b other HEAD^\n>>   sed s/4/other/ <file >tmp && mv tmp file\n>>   git commit -am other\n>>\n>>   git merge master\n>>   git checkout --ours file\n>>   git commit -am merged\n>>\n>>   merge=$(git rev-parse HEAD)\n>>\n>> The question is: were there conflicts in $merge, and how were they\n>> resolved?\n>>\n>> That isn't an evil merge, but there's still something interesting to\n>> show that \"git log --cc\" won't display.\n>>\n>> Replaying the merge like:\n>>\n>>   git checkout $merge^1\n>>   git merge $merge^2\n>>   git diff -R $merge\n>>\n>> shows you the patch to go from the conflict state to the final one.\n>>\n> \n> I know the stackoverflow question asks \"how to detect evil merges\",\n> and I go along with that in my answer.  But honestly I prefer to call\n> them dirty rather than evil, and by \"dirty\" I just mean merges that\n> did not resolve cleanly via \"git merge\", and had some form of user\n> intervention, be it conflict resolution, or other strange things.\n> \n> The trick I propose with the sequence of 4 \"git diff\" commands\n> identifies that merge from your example as dirty:\n> \n> $ cat b1 m2\n> file\n> \n> $ cat b2 m1\n> file\n> file\n> \n> The trick doesn't really tell you much except that the merge is dirty.\n> If you notice that the \"m2\" file is empty, I think that's one way to\n> realize that master's edit was dropped, and therefore \"other\" won.\n> \n> Maybe it even merged cleanly but someone did a \"git commit --amend\" to\n> make it the merge dirty after the fact.\n> \n> I do like your approach, it's very simple and reliable.  But in my\n> situation I'm writing pre-receive hooks for bare repos, so I don't\n> think I can actually do \"git merge\"!\n> \n> I think my suggestion would work for OP, as long as they also run \"git\n> show -c\" alongside it.   (And your suggestion would work, too, of\n> course).\n\nIf you're curious, I kept rebasing Thomas' remerge-diff (on top of our\nnext) so far. You can find it at\n\nhttps://github.com/mjg/git/tree/remerge-diff\n\nif you're interested. I don't know what problems were found back then,\nor what it would take to get this in-tree now.\n\nMichael\n\n"},{"id":"312766","messageId":"xmqqr32jwh7o.fsf@gitster.mtv.corp.google.com","threadId":"44988","inReplyTo":"6ff25254-720e-5b85-ba6d-22b16e91b354@drmicha.warpmail.net","subject":"Re: show all merge conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-27T19:45:31Z","receivedAt":"2017-02-27T19:54:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> If you're curious, I kept rebasing Thomas' remerge-diff (on top of our\n> next) so far. You can find it at\n>\n> https://github.com/mjg/git/tree/remerge-diff\n\n;-).\nYes, this was a good one.  \n\n\n> if you're interested. I don't know what problems were found back then,\n> or what it would take to get this in-tree now.\n\nIf I recall correctly, everybody was in favor of what it does (or at\nleast attempted to do), but was leaky and not ready for \"log -p\" to\nbe used on a long stretch of history or something?\n"},{"id":"312772","messageId":"20170227204549.75aajp3rpsgl6fhz@sigill.intra.peff.net","threadId":"44988","inReplyTo":"xmqqr32jwh7o.fsf@gitster.mtv.corp.google.com","subject":"Re: show all merge conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-27T20:45:49Z","receivedAt":"2017-02-27T21:13:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 27, 2017 at 11:45:31AM -0800, Junio C Hamano wrote:\n\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n> > If you're curious, I kept rebasing Thomas' remerge-diff (on top of our\n> > next) so far. You can find it at\n> >\n> > https://github.com/mjg/git/tree/remerge-diff\n> \n> ;-).\n> Yes, this was a good one.\n\nFWIW, I have also been carrying it forward. It's not a tool I reach for\noften, but a couple of times it has come in very handy (mostly helping\nsomebody to track down a mistake that somebody made in a merge, like\naccidentally using \"checkout --ours\" on top of a conflict).\n\n> > if you're interested. I don't know what problems were found back then,\n> > or what it would take to get this in-tree now.\n> \n> If I recall correctly, everybody was in favor of what it does (or at\n> least attempted to do), but was leaky and not ready for \"log -p\" to\n> be used on a long stretch of history or something?\n\nThe last round was at:\n\n  http://public-inbox.org/git/cover.1409860234.git.tr@thomasrast.ch/\n\nI think. I think the leakiness was dealt with by rebasing onto the\nname_hash refactoring. But it looks like there are a lot of little\nissues, and maybe one bigger one: it turns \"log\" from a read-only\noperation into that writes into the object database.\n\n-Peff\n"}]}