# Re: Wine + GIT 3 messages from 2005-12-08 to 2005-12-08. Participants: linux@horizon.com, Fredrik Kuivinen, Junio C Hamano. Thread: https://gitlist.dev/t/2775 ## linux@horizon.com, 2005-12-08 07:30 Subject: Re: Wine + GIT Message-ID: <20051208073000.7097.qmail@science.horizon.com> URL: https://gitlist.dev/e/20051208073000.7097.qmail%40science.horizon.com ``` > The paragraph "Once you have finished editting [sic]..." needs > to be followed by: > > git-update-index those paths you hand corrected > git-commit This is what happens when you have people too used to using the pre-porcelain plumbing. How about just git-commit If you forget any, the commit will fail, but they will have been updated in the index, and you don't need to mention them again in the next attempt. (Grump... I just noticed that the "recursive" merge stratgy *doesn't* generate a merged file containing conflict markers, at least not in the case I tried. Instead I get "a~HEAD" and "a~branch" files. Time to fix the docs...) ``` ## Fredrik Kuivinen, 2005-12-08 09:29 Subject: Re: Wine + GIT Message-ID: <20051208092945.GA4921@c165.ib.student.liu.se> URL: https://gitlist.dev/e/20051208092945.GA4921%40c165.ib.student.liu.se In-Reply-To: <20051208073000.7097.qmail@science.horizon.com> ``` On Thu, Dec 08, 2005 at 02:30:00AM -0500, linux@horizon.com wrote: > (Grump... I just noticed that the "recursive" merge stratgy *doesn't* > generate a merged file containing conflict markers, at least not in > the case I tried. Instead I get "a~HEAD" and "a~branch" files. > Time to fix the docs...) In the most common case, i.e., when you have a file 'a' in the common ancestor and 'a' have been modified in both A and B (where A and B are the branches we are going to merge) then the recursive strategy should generate a merged file with merge(1), which will produce conflict markers if there are conflicts. Any other behaviour is a bug. However, in some other cases such as rename/rename, file/directory and add/add conflicts "a~A" and "a~B" will be created in the working directory. The recursive strategy will (or, is supposed to) tell you about such things, though. - Fredrik ``` ## Junio C Hamano, 2005-12-08 18:17 Subject: Re: Wine + GIT Message-ID: <7v4q5jjvws.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v4q5jjvws.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20051208092945.GA4921@c165.ib.student.liu.se> ``` Fredrik Kuivinen writes: > However, in some other cases such as rename/rename, file/directory and > add/add conflicts "a~A" and "a~B" will be created in the working > directory. The recursive strategy will (or, is supposed to) tell you > about such things, though. I think one reason for this was because read-tree -m was the only way to create higher stage entries in the index, and after detecting renames, the recursive merge strategy did not have a good way to insert these as different stages in the index. I extended update-index --index-info a little bit to let people insert higher stage entries in the index, so we could if we wanted to. Here are the differences I know about between resolve and recursive other than ~A ~B: - in add/add case, merge-one-file tries to be cuter and leaves conflict-marked merge result. - content conflict in a renamed path gets its index entry collapsed, unlike other content conflicts. ```