The section 'Open Revisions Affecting These Files' can be daunting and skipped over if there is a lot of noise. One means of possibly dealing with this is weighting the severity of the possible overlapping diffs. Some things to consider:
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Wontfix | epriestley | T6853 "Open Revisions Affecting These Files" should weight severity of changes | ||
| Open | None | T784 Allow Differential changesets to be marked with various attributes |
Take D11149: Remove an unused class for example. Under "Open Revisions Affecting These Files", the following diffs are listed:
I believe that these diffs are listed because src/__phutil_library_map__.php is modified (although I could be wrong).
It's important for us to understand the core problem, as well as separate out Phabricator development from 'real development'.
If these are false positives that disrupt your workflow, I want to know what that workflow is. There may be other tasks or solutions that are better suited and solve more problems.
https://secure.phabricator.com/book/phabcontrib/article/feature_requests/
The main issue as I see it is "Open Revisions..." are useless, at least on this install, and possibly many others. T5658 covers perhaps a better query, and maybe a better fix is to have some sort of "severity" of overlap indicated instead. Generated files would be very low, but multiple files might be very high.
@generated files.
We can plausibly ignore generated files, although this is complex and expensive because detecting that a file is generated depends on configuration, event hooks, examining the file content, examining diff properties, and possibly fishing around in repositories.
Changes with multiple file overlaps
We can plausibly do this, but I don't think there's any reason to believe that this is a good rule. In particular, I worry that this will create a lot of false negatives, because editing a single file can be important.
Changes moving files being editing
This is expensive to compute and complex to implement (we need to load all candidate revisions, load their changesets, and then compare them). This doesn't seem too important to me.
Overall:
Just to let you know, I used this panel to find out all of the revisions that were affecting individual Drydock files so that I could merge down changes correctly.
We made this a little smarter and a little less prominent (on a non-default tab) and I feel like it's generally in a more reasonable place now. I don't currently expect to make it significantly more complex, and none of the rules proposed here feel like simple, unambiguous improvements to me.