>> Yes, we discussed this one the list before. The fossil should at >> least warn about it, or more accurately raise a conflict, because >> that's what it really is. It's a bug.
> I can see a desire to raise a merge conflict, but I don't think it > is a bug. Isn't it reasonable to say "removing the file from a > branch means the file is no longer tracked in the branch, and thus > no actions should be taken on an untracked file"? It is reasonable, if the removal happened *at the branch*. But it is being brought by merge from elsewhere, say trunk. In that context, it is confusing. Additionally, what frequently happens next is that the file gets re-added on the branch to keep going, and when the finished code gets merged back to the trunk, "no common ancestor" warnings just keep on surprising. From design point of view, I think Fossil should not be implying that delete is any more special than the update. Treating both the same and raising conflicts, in the same fashion as currently happens with updates, would give the opportunity to user to decide what to do. > By extension, if you have a working copy, you remove a file (stop > tracking the file), then make some changes to the file, do you > expect fossil to warn you there are changes to a no longer tracked > file? No, of course not. But this is about deletions happening elsewhere and being brought in by merge. I think a more appropriate example is the one I provided above. > What does git do in this case? You mean how it handles merge of deleted files? I honestly don't know, I'm not using Git. >> Since we've got Richard's attention to this thread, I'd point him >> to related bugs that were reported before. Maybe these should be >> entered as tickets so we don't lose track of them. >> >> 1. (In May) Anofos reported that renaming a file on the branch and >> adding it back later results in lost file when merged back to >> trunk. Git does the right thing. >> >> http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20417.html >> >>2. (In June) Andy G reported after renaming file in a branch, >> merging trunk changes to it works only once, and subsequent merges >> do nothing: >> >> http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html > I'm not sure what to do with renaming. I don't know how Fossil deals with merging renames internally, but these are bugs, clearly. I have noted them again in case they may be related to current implementation of merging deletes. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
