I can imagine a lot of people being annoyed if auto resolution was to add a file previously deleted from a branch back to the branch. I can see that being every bit as confusing to them as it not being re-added is to you. Just as my deleted text a month ago was to me.
The difference is that re-adding is showing up in 'fossil status', which is then easy to reverse by grepping it's output and piping to delete before commit; while for no-op, as currently is the case, you are not aware there is a potential problem at all. And if/when you figure out that files are missing, you'd have to resurrect and manually add them one by one. But I wouldn't mind if, instead of no-op, status just shows that the ancestor was removed and current edits are therefore ignored. I can then equally grep for it and then bulk add it, if necessary. It would be interesting to know what others on the list think. It would be more cumbersome to describe, in my opinion - see below example. I think the crucial thing here is the distinct indicator by the merge that this situation is encountered, so you can then choose to act if appropriate. How it is auto-resolved is less important. For example, this indicator could be a status like 'CONFLICT', but would be auto-resolved to allow commit. For example, 'READDED_BY_MERGE' or, in your case, 'KEPT_DELETED_BY_MERGE' or 'IGNORED_CHANGES_ANCESTOR_MISSING'. On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich <s...@stef.rs<mailto:s...@stef.rs>> wrote: ?I'd argue this is not intuitive, especially to a new Fossil user. "Losing" the file like this and not reporting at least as a warning seems like a wrong design choice, to me. I'd agree it is not intuitive, as it took some hours of my time when I thought I'd found a bug a month ago to trace through the code looking for a flaw that didn't exist. I had told it at one point in time to merge in a deletion into my branch, and so when it came time to play catch up to trunk, it did what I had told it to do previously: Keep text previously deleted out of the new merge, even though in this case I needed to readd something due to other changes in fossil. I actually like flagging the file as a conflict, with auto-resolution being to keep (re-add) the file. If this is tagged distinctively, then it is very easy - when you don't want the files re-introduced - to grep the output of 'fossil status' and bulk delete such files before committing the merge. I can imagine a lot of people being annoyed if auto resolution was to add a file previously deleted from a branch back to the branch. I can see that being every bit as confusing to them as it not being re-added is to you. Just as my deleted text a month ago was to me. But at least a warning would be very useful. We already have warnings when files don't have common ancestors while merging (the cause of which confused me enough times and is probably related to this). How about this scenario: 1. Trunk is the mainline branch from which releases are made. 2. Feature is a branch for ongoing development of some feature. 3. Periodically you merge trunk into feature so that you don't drift too far (up to and including just before the final merge back to trunk). 4. In the end, you merge from the feature back to trunk when everything is ready for release. I think in this case you'd get the warning you seek because in the parent branch it had been deleted while being edited in the child branch (the nearest common ancestor was on trunk). I think you're right about the common ancestor confusion. I certainly can see the point about "deletion from one branch and edits in another branch being arguably a conflict requiring resolution". I'm just can't think of a better way to handle it than at present. This is probably why I don't get paid the big bucks. -- Scott Robison
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
