{"thread":{"id":"15958","subject":"\"git checkout: --track and --no-track require -b\" check accidentally resurrected?","startedAt":"2008-10-19T00:54:12Z","lastAt":"2008-10-20T16:17:08Z","messageCount":5,"participants":["Matt McCutchen","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93404","messageId":"1224377652.19061.12.camel@mattlaptop2.local","threadId":"15958","inReplyTo":null,"subject":"\"git checkout: --track and --no-track require -b\" check accidentally resurrected?","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2008-10-19T00:54:12Z","receivedAt":"2008-10-19T00:54:12Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"Merge commit 9ba929ed resurrected the following two-line check, which\nwas removed in the first parent and unchanged in the second:\n\n\tif (!opts.new_branch && (opts.track != git_branch_track))\n\t\tdie(\"git checkout: --track and --no-track require -b\");\n\nIs this intentional?  Does it make a difference?\n\n(I noticed this while carefully examining 9ba929ed to find out why \"git\nmerge\" stopped honoring merge.conflictstyle.  Ironically, I hit this bug\nagain during the examination.)\n\nMatt\n"},{"id":"93447","messageId":"7vhc785izq.fsf@gitster.siamese.dyndns.org","threadId":"15958","inReplyTo":"1224377652.19061.12.camel@mattlaptop2.local","subject":"Re: \"git checkout: --track and --no-track require -b\" check accidentally resurrected?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-19T22:15:53Z","receivedAt":"2008-10-19T22:15:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt McCutchen <matt@mattmccutchen.net> writes:\n\n> Merge commit 9ba929ed resurrected the following two-line check, which\n> was removed in the first parent and unchanged in the second:\n>\n> \tif (!opts.new_branch && (opts.track != git_branch_track))\n> \t\tdie(\"git checkout: --track and --no-track require -b\");\n>\n> Is this intentional?  Does it make a difference?\n>\n> (I noticed this while carefully examining 9ba929ed to find out why \"git\n> merge\" stopped honoring merge.conflictstyle.  Ironically, I hit this bug\n> again during the examination.)\n\nAgain, good eyes.  I think the two lines should go; my fault at cdb22c4\n(Merge branch 'jc/better-conflict-resolution' into next, 2008-09-02).\n\nThanks.\n"},{"id":"93446","messageId":"7v3ais5hb3.fsf_-_@gitster.siamese.dyndns.org","threadId":"15958","inReplyTo":"7vhc785izq.fsf@gitster.siamese.dyndns.org","subject":"Is XDL_MERGE_ZEALOUS too zealous (or maybe not zealous enough)?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-19T22:52:16Z","receivedAt":"2008-10-19T22:52:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Again, good eyes.  I think the two lines should go; my fault at cdb22c4\n> (Merge branch 'jc/better-conflict-resolution' into next, 2008-09-02).\n\nHmm, I am somewhat unhappy.  If you run:\n\n\t$ git checkout cdb22c4^\n        $ git merge cdb22c4^2\n\t$ git checkout --conflict=diff3 builtin-checkout.c\n\nand look at builtin-checkout.c.  You will find this:\n\n<<<<<<< ours\n\t/* --track without -b should DWIM */\n\tif (0 < opts.track && !opts.new_branch) {\n\t\tconst char *argv0 = argv[0];\n\t...\n\t\topts.new_branch = argv0 + 1;\n\t}\n\n\tif (opts.track == BRANCH_TRACK_UNSPECIFIED)\n\t\topts.track = git_branch_track;\n|||||||\n\tif (!opts.new_branch && (opts.track != git_branch_track))\n\t\tdie(\"git checkout: --track and --no-track require -b\");\n=======\n\tif (conflict_style) {\n\t\topts.merge = 1; /* implied */\n\t\tgit_xmerge_config(\"merge.conflictstyle\", conflict_style, NULL);\n\t}\n\n\tif (!opts.new_branch && (opts.track != git_branch_track))\n\t\tdie(\"git checkout: --track and --no-track require -b\");\n>>>>>>> theirs\n\nThe two lines in the middle was from the common ancestor, which was not\ntouched by the merged branch (that added the \"if (conflict_style) {}\"\nblock) and was lost by a rewrite in \"ours\".\n\nHowever, the usual simplified merge shows this (run \"git checkout --merge\nbuiltin-checkout.c\" if you have done the above):\n\n<<<<<<< ours\n\t/* --track without -b should DWIM */\n\tif (0 < opts.track && !opts.new_branch) {\n\t\tconst char *argv0 = argv[0];\n\t...\n\t\topts.new_branch = argv0 + 1;\n\t}\n\n\tif (opts.track == BRANCH_TRACK_UNSPECIFIED)\n\t\topts.track = git_branch_track;\n=======\n\tif (conflict_style) {\n\t\topts.merge = 1; /* implied */\n\t\tgit_xmerge_config(\"merge.conflictstyle\", conflict_style, NULL);\n\t}\n\n\tif (!opts.new_branch && (opts.track != git_branch_track))\n\t\tdie(\"git checkout: --track and --no-track require -b\");\n>>>>>>> theirs\n\nRemoving the two lines from the simplified \"theirs\" is not what I would\nsuggest (it would be actively wrong), but I wonder if we can do something\nclever to help users with a merge like this.\n"},{"id":"93439","messageId":"1224474120.19785.3.camel@mattlaptop2.local","threadId":"15958","inReplyTo":"7v3ais5hb3.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Is XDL_MERGE_ZEALOUS too zealous (or maybe not zealous enough)?","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2008-10-20T03:42:00Z","receivedAt":"2008-10-20T03:42:00Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Sun, 2008-10-19 at 15:52 -0700, Junio C Hamano wrote:\n> However, the usual simplified merge shows this (run \"git checkout --merge\n> builtin-checkout.c\" if you have done the above):\n> \n> <<<<<<< ours\n> \t/* --track without -b should DWIM */\n> \tif (0 < opts.track && !opts.new_branch) {\n> \t\tconst char *argv0 = argv[0];\n> \t...\n> \t\topts.new_branch = argv0 + 1;\n> \t}\n> \n> \tif (opts.track == BRANCH_TRACK_UNSPECIFIED)\n> \t\topts.track = git_branch_track;\n> =======\n> \tif (conflict_style) {\n> \t\topts.merge = 1; /* implied */\n> \t\tgit_xmerge_config(\"merge.conflictstyle\", conflict_style, NULL);\n> \t}\n> \n> \tif (!opts.new_branch && (opts.track != git_branch_track))\n> \t\tdie(\"git checkout: --track and --no-track require -b\");\n> >>>>>>> theirs\n> \n> Removing the two lines from the simplified \"theirs\" is not what I would\n> suggest (it would be actively wrong), but I wonder if we can do something\n> clever to help users with a merge like this.\n\nIMHO, the solution is just to use diff3 style.  I never understood how I\nwas supposed to intuit the correct result of a merge from the two sides\nwithout seeing the common ancestor, so I am glad to have the diff3 style\nworking now.\n\nMatt\n"},{"id":"93544","messageId":"alpine.DEB.1.00.0810201809100.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15958","inReplyTo":"7v3ais5hb3.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Is XDL_MERGE_ZEALOUS too zealous (or maybe not zealous enough)?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-20T16:17:08Z","receivedAt":"2008-10-20T16:17:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 19 Oct 2008, Junio C Hamano wrote:\n\n> <<<<<<< ours\n> \t/* --track without -b should DWIM */\n> \tif (0 < opts.track && !opts.new_branch) {\n> \t\tconst char *argv0 = argv[0];\n> \t...\n> \t\topts.new_branch = argv0 + 1;\n> \t}\n> \n> \tif (opts.track == BRANCH_TRACK_UNSPECIFIED)\n> \t\topts.track = git_branch_track;\n> =======\n> \tif (conflict_style) {\n> \t\topts.merge = 1; /* implied */\n> \t\tgit_xmerge_config(\"merge.conflictstyle\", conflict_style, NULL);\n> \t}\n> \n> \tif (!opts.new_branch && (opts.track != git_branch_track))\n> \t\tdie(\"git checkout: --track and --no-track require -b\");\n> >>>>>>> theirs\n\nThis is that case that adjacent blocks A and B are changed to A' B and A \nB' in the to-be-merged branches.\n\nI could imagine that you would have this automerged to A' B', but I \nactually advise against that.\n\nMy gut feeling tells me that a \"for\" statement as block \"A\" and some \nchange (\"B\") in the _body_ of the \"for\" loop that takes advantage of the \noriginal version of the \"for\" statement would be _real_ hard to detect.\n\nBetter have trivial conflicts reported, but catch more non-trivial ones \n(instead of mismerging them).\n\n(Another possibility would be that block \"B\" is actually an \"else\".  Also \nin this case it is easy to think of cases that would wreak havoc; OTOH we \nwould mismerge them _already_ if at least 1 common line is unchanged \nbetween the blocks.  Tough.)\n\nBut I might be completely wrong.\n\nCiao,\nDscho \"who is a little jet-lagged, so you should trust him even less than \nnormally\"\n"}]}