{"thread":{"id":"2775","subject":"Re: Wine + GIT","startedAt":"2005-12-08T07:30:00Z","lastAt":"2005-12-08T18:17:23Z","messageCount":3,"participants":["linux@horizon.com","Fredrik Kuivinen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13350","messageId":"20051208073000.7097.qmail@science.horizon.com","threadId":"2775","inReplyTo":null,"subject":"Re: Wine + GIT","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2005-12-08T07:30:00Z","receivedAt":"2005-12-08T07:30:00Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> The paragraph \"Once you have finished editting [sic]...\" needs\n> to be followed by:\n> \n>\tgit-update-index those paths you hand corrected\n>        git-commit\n\nThis is what happens when you have people too used to using the\npre-porcelain plumbing.\n\nHow about just\ngit-commit <the paths you hand corrected>\n\nIf you forget any, the commit will fail, but they will have been\nupdated in the index, and you don't need to mention them again in the\nnext attempt.\n\n\n(Grump... I just noticed that the \"recursive\" merge stratgy *doesn't*\ngenerate a merged file containing conflict markers, at least not in\nthe case I tried.  Instead I get \"a~HEAD\" and \"a~branch\" files.\nTime to fix the docs...)\n"},{"id":"13353","messageId":"20051208092945.GA4921@c165.ib.student.liu.se","threadId":"2775","inReplyTo":"20051208073000.7097.qmail@science.horizon.com","subject":"Re: Wine + GIT","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2005-12-08T09:29:45Z","receivedAt":"2005-12-08T09:29:45Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Thu, Dec 08, 2005 at 02:30:00AM -0500, linux@horizon.com wrote:\n> (Grump... I just noticed that the \"recursive\" merge stratgy *doesn't*\n> generate a merged file containing conflict markers, at least not in\n> the case I tried.  Instead I get \"a~HEAD\" and \"a~branch\" files.\n> Time to fix the docs...)\n\nIn the most common case, i.e., when you have a file 'a' in the common\nancestor and 'a' have been modified in both A and B (where A and B are\nthe branches we are going to merge) then the recursive strategy should\ngenerate a merged file with merge(1), which will produce conflict\nmarkers if there are conflicts. Any other behaviour is a bug.\n\nHowever, in some other cases such as rename/rename, file/directory and\nadd/add conflicts \"a~A\" and \"a~B\" will be created in the working\ndirectory. The recursive strategy will (or, is supposed to) tell you\nabout such things, though.\n\n\n- Fredrik\n"},{"id":"13356","messageId":"7v4q5jjvws.fsf@assigned-by-dhcp.cox.net","threadId":"2775","inReplyTo":"20051208092945.GA4921@c165.ib.student.liu.se","subject":"Re: Wine + GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-08T18:17:23Z","receivedAt":"2005-12-08T18:17:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Kuivinen <freku045@student.liu.se> writes:\n\n> However, in some other cases such as rename/rename, file/directory and\n> add/add conflicts \"a~A\" and \"a~B\" will be created in the working\n> directory. The recursive strategy will (or, is supposed to) tell you\n> about such things, though.\n\nI think one reason for this was because read-tree -m was the\nonly way to create higher stage entries in the index, and after\ndetecting renames, the recursive merge strategy did not have a\ngood way to insert these as different stages in the index.\n\nI extended update-index --index-info a little bit to let people\ninsert higher stage entries in the index, so we could if we\nwanted to.\n\nHere are the differences I know about between resolve and\nrecursive other than ~A ~B:\n\n - in add/add case, merge-one-file tries to be cuter and leaves\n   conflict-marked merge result.\n\n - content conflict in a renamed path gets its index entry\n   collapsed, unlike other content conflicts.\n"}]}