![]() ![]() > But I wonder if this argument is enough? > exactly that (refer to same tree in G) quasi on the direct route, per > was created with the default merge strategy. > tree (as G's only purpose is to serve as a new merge basis), even if G > Of course, logically I expected that commits F and G have the same > However, I'm unsure if this is the proper solution: > worked quickly and without any problems, and created the new merge > I really should have thought of trying this myself. > two tree 'compatible' -) which will establish a new merge base for ![]() > trying to do more than it needs to, given that you will already have > Also you could simply try an Ours/Theirs strategy (as appropriate) The result would have technically been exactly the same? Somehow solved all the conflicts (so that none of the files had been changed from F), That is, do I understand correctly that if I had used the default merge strategy, and The "ours" strategy does exactly that (refer to same tree in G) quasi on the Purpose is to serve as a new merge basis), even if G was created with the default merge Of course, logically I expected that commits F and G have the same tree (as G's only However, I'm unsure if this is the proper solution: Worked quickly and without any problems, and created the new merge commit G just as I really should have thought of trying this myself. > two tree 'compatible' -) which will establish a new merge base for future merges. > trying to do more than it needs to, given that you will already have carefully made the > Also you could simply try an Ours/Theirs strategy (as appropriate) which would stop git > CONFLICT (rename/delete): Version master of > #, then after the last: > Automatic merge failed fix conflicts and then commit the result.īut while the messages are slightly different now, the result is essentially the same, > warning: you may want to set your merge.renamelimit variable to at least 8288 and retry the command. > warning: inexact rename detection was skipped due to too many files. In this case, I understand even less whatĪfter about 2000 of these messages, the merge aborts with: > CONFLICT (rename/rename): Rename "xmlrpc/includes/index.html"->"in "master"Īnd this occurs apparently for *every* other file (even though the mentioned file isġ00% identical, same SHA-1, in both branches). Was moving things into www/ ), I don't seem to understand what this message means, much > CONFLICT (rename/delete): Version master of I believe this is for all those that I have modified in "develop". I just tried this again in order to capture the full error messages it provides:īeing on branch "develop" at commit F, running "git merge master" yields two types of Thanks for your reply! Repeating the move commands for each branch and a flag day commitįor each is what I tried already: see the second attempt in my original mail, commits F It will normally show the file renames just in case. > At least then the file rename machinery has much less to worry about for any (real) Then the development merging should proceed just fine. > repeat the moves as a script once for each branch, so that each branch has a flag day > Surley (?) the simplest method, given your limited number of branches, is to capture and Reported conflict was that the file has been renamed on one side, and has been renamedĬafu - the open-source Game and Graphics Engineįor multiplayer, cross-platform, real-time 3D Action Unfortunately I didn't keep a copy of the exact messages, but essentially the To my surprise, this caused conflicts for quasi every of the affected 11000 files as Tried to merge "master" into "develop" to obtain G: So I deleted E again (reset "develop" back to D), repeated the above move-and-commitĬommands at D in order to mimic things in the "develop" branch, obtaining F, and *then* Various directories that M doesn't have, and several files with small changes as well. O-o-o-o-.-M -N <- masterīut this yields plenty of merge conflicts, probably because D has several files in ![]() Then to merge this into "develop" in order to obtain E: I tried the above move-and-commit commands first at commit M, yielding new commit N, *and* in "master", in order to be able to do future merges from "master" into "develop" This is easy, but the problem is that we eventually have to do this *both* in "develop" Git commit -m "Moved everything into www/." # Git version is 1.7.11.msysgit.1 on Windows 7. Into a new subdirectory "www", for example like this: Now we have found a need to reorganize our files and directories, moving "everything" (WeĬreate our releases off the "develop" branch, not "master".) We have a repository with essentially this commit graph:Īs shown, we occasionally merge "master" into "develop", but never vice-versa. ![]()
0 Comments
Leave a Reply. |