{"thread":{"id":"43771","subject":"What's in git.git \"next\"","startedAt":"2006-10-28T02:09:20Z","lastAt":"2006-10-28T02:09:20Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298423","messageId":"7vr6wtb38v.fsf@assigned-by-dhcp.cox.net","threadId":"43771","inReplyTo":null,"subject":"What's in git.git \"next\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-28T02:09:20Z","receivedAt":"2006-10-28T02:09:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've fixed up merge-recursive not to warn \"working file will be\nclobbered\" when unneeded, and merged it to \"next\" tonight.  This\nis a usability fix but if done incorrectly we can break a safety\nvalve.\n\nThe \"next\" version changes behaviour from the traditional one\nwhen (1) paths that are untracked in our branch exists in the\ncommon ancestor and the other branch we merge into our branch,\n(2) the other branch did not make any changes to these paths,\nand (3) the working tree has these paths as untracked files.\n\nUnder this condition, 3-way merge decides the path should not\nexist in the result.  This has not been changed (and shouldn't\nbe).  But what is being fixed is what \"should not exist\" means.\nWe used to say \"we have that path in our working tree, which\nwill be lost by the merge, so we won't merge\".  Which was\nperhaps safer but was inconvenient.  The corrected behaviour\nshould be \"the path is not tracked in our branch, and the result\nof the merge won't have it tracked either, and we will leave\nthose untracked working tree files as they were\".\n\nI added a handful tests to t6022 to catch potential breakages,\nand the code still passes them, but that does not mean it is\nperfect.  If the program refuses to proceed when it can, you\nfound a safer breakage I do not worry too much about.  If the\nprogram overwrites or loses an untracked working tree file as a\nresult of the merge, then that means the updated merge-recursive\nrelaxed the check too much.\n\nSo please handle this with a bit of extra care than usual; I'd\nappreciate extra sets of eyeballs to sanity check.\n"}]}