Luben Tuikov <ltuikov@xxxxxxxxx> writes: > --- Junio C Hamano <junkio@xxxxxxx> wrote: >> Luben Tuikov <ltuikov@xxxxxxxxx> writes: >> >> > I think this is a good thing. >> > >> > How about this case I've noticed in my trees: >> > >> > After branching out, a file is deleted, only to add >> > a different file with the same file name. >> > >> > Then any time I pull in from the trunk to merge, >> > merge fails with git-diff-files showing all 0's and the >> > file name in question. Picture: >> > >> > Branch B +-----------------M1----> >> > / / >> > C2 <-- git-add A / >> > / / >> > C1 <-- git-rm A / >> > / / >> > Trunk -----+-----------------+----> >> >> Sorry I do not understand the picture; where is the common >> ancestor? If it is the left plus sign on the Trunk line, and > > Yes, the left plus sign is the common ancestor. > >> you are talking about what happens when making the merge M1, >> then before C1 A did not exist (so Trunk tip which is the right > > File A exists before C1, it does not exist after C1. C1 removes > it. Ah, I misunderstood. But then I do not understand why you see all 0 anywhere. Merge base has the path, branch B has it, and trunk has it too; wouldn't it result in regular 3-way merge? I understand you do _not_ even want a regular 3-way merge in this case, but that is a separate issue. You could write a new merge strategy to traverse ancestry chain between the merge base and each heads you are merging and notice disappearance and reappearance of the path, but that would slow things down tremendously for normal case and I do not think it is worth it. You would also have exactly the same issue if you do not remove and then add the file, but if your work on the branch involves a significant rewrite. Depending on how good the rewrite is, bugfixes that happened on the trunk based on an ancient code may not even be needed (in other words, it would not apply cleanly anyway, but it does not matter -- the branch work is much better or has different set of problems that the trunk fix is irrelevant). At that point, M1 would involve significant merge conflicts (and not all-0 which I am still puzzled about), but I suspect that the situation is obvious enough to the human (inspect git log branch...trunk output and the log somewhere had better indicate that the are unrelated), and the solution very much is different case-by-case (most likely the person who pulls branch into trunk would say "keep ours" for the path which would mean running "git cat-file :2:$path >$path", or say "we are not really ready to merge yet" and abort the entire merge; somebody on the trunk pulling from that branch might say "I want other smaller fixes but this total rewrite is not ready yet -- keep ours", or "now we know this is total rewrite and the small updates on the trunk does not matter -- take theirs and from now on we will improve on the work done on the branch"). So in short, I do not think there is a clear-cut improvement we can do to the tools to solve this. - 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