On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich <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
