View Ticket
Not logged in
Ticket UUID: 4df5f38f1e564d2970c269bf5ea1d2aec5173dc9
Title: Troubles merging a file delete with a file change
Status: Review Type: Feature_Request
Severity: Priority:
Subsystem: Resolution: Rejected
Last Modified: 2011-08-30 14:22:37
Version Found In: 1.18
Description & Comments:
I have a branch where I have modified a.cpp. If in trunk someone deleted that file, and I run fossil update trunk, fossil will silently merge the branch modifications and the trunk delete silently into a file delete.

Fossil should report this as a conflict.


drh added on 2011-08-30 14:22:37 UTC:
Whether or not this should be reported as a conflict is a matter of opinion. Technically, whenever two people make any changes to a file in parallel, the resulting merge is a conflict. We choose not to report conflicts that can be cleanly joined together. For example, we choose not to report conflicts when the two edits are in different parts of the same file. Just because two edits happen to merge together cleanly and without overlap does not mean that the resulting code will still run, after all.

Even edits in separate files are potentially a conflict, since while both edits might work fine separately, their combination might make the software fail. So, technically, any parallel change to the project is a conflict. But we choose not to make a big deal out of most of these conflicts since most of the time they are benign.

The tricky part in a merge algorithm is to identify and announce conflicts that are likely to require programmer intervention and resolution, versus conflicts that the software is probably able to deal with itself. You don't want to announce too many conflicts, because - as with the boy who cried "Wolf!" - users quickly develop conflict-fatigue and end up ignoring real problems.

In the case of an edit/delete conflict, the software currently thinks it can deal with that itself. If you want to disagree, then give us some specific cases where that policy causes issues and argue your case. In the absence of a more compelling rationale, I don't think this complaint warrants any changes to the current merge logic.