Fabian Kössel <mok4sin@xxxxxxxxxxxxxx> writes: > On 22.02.2010 23:32, Junio C Hamano wrote: >> I'll queue with a trivial addition of "rm builtin/*.o" to the "make > clean" >> target. I am not looking forward to merging the result of this with > other >> topics, though... X-<. > > Just out of curiosity, how do you actually merge such a relatively big > rename with other branches? For git.git, existing files are not so troublesome. merge-recursive knows how to handle renames, so does "am -3", but the latter is tricky when the contributor based a patch on some unknown vintage of the source. A topic with a new builtin command is a bit problematic and no mechanical merge would help. I suspect that no other SCM would be able to either. - A topic that adds builtin-frotz.c has an entry that describes how to build builtin-frotz.o in Makefile, somewhere near Linus's topic changes an existing builtin-nitfol.o to builtin/nitfol.o. The topic would have added the new target already, and then we are merging Linus's topic. The merge will conflict. Every time I rebuild 'pu', this conflict will reappear over and over. But once the conflict is resolved, rerere will remember it for me, so this is not a big problem. - A new builtin-frotz.c file in such a topic is more problematic. Linus's patch does not know anything about it, so it will merge cleanly, but the merge will not move it to builtin/frotz.c; this needs to be fixed manually as an evil merge. I have automated such an evil merge so that I can rebuild 'pu' without manual intervention. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html