Page MenuHomePhabricator

Previous revisions not being assigned to parent repository
Closed, WontfixPublic

Description

This is possibly related to T4746. After re-importing a repository, differentials correctly link to a commit from the parent repository, but they were not automatically added to the repository itself (i.e. the repositoryPHID field of the diff/revision was not set).

Is this the expected behaviour? I feel that if a differential is linked to a commit from repository rX then probably the differential itself should be linked to rX as well.

Event Timeline

joshuaspence assigned this task to epriestley.
joshuaspence raised the priority of this task from to Normal.
joshuaspence updated the task description. (Show Details)
joshuaspence updated the task description. (Show Details)
joshuaspence added a subscriber: joshuaspence.

When you say "correctly link to a commit", what do you mean specifically? My guesses are either:

  • When a commit appears in the remote, it is correctly associated with the revision (and causes it to close in some cases)? This would be in the "Commits" property at the top.
  • In the "Local Commits" or "Revision Update History" tables, commit hashes are linked into the repository?

What I mean exactly is that I have a differential with the following properties:

  • Diff has been accepted (and code has been merged into master branch)
  • "Commits" field in the differential view correctly links to the corresponding commit on the master branch.
  • "Repository" field in the differential view is not set.

I would expect that, at the same time that rX123 is set as the commit for the differential, the repository for the differential is set to rX.

Okay -- it's expected that this won't happen. Offhand, some cases where this rule would be a bit ambiguous are:

  • The repository might not be set because a user explicitly removed it. It seems odd to put it back in this case.
  • Commits for a revision can land in multiple repositories. If we fill repositories, but revisions are routinely committed to multiple repositories, we'll arbitrarily pick the first repository where a commit happens to land, producing inconsistent results. This sounds crazy (and is) but offhand I know of at least one install where something like this is fairly routine.

These are edge cases, but it sounds like your situation is an edge case too. Broadly, adopting this rule would increase complexity (we'd need to add code for it), rarely do anything, and occasionally do something ambiguous/wrong.

The expected behavior is that we adjust repositoryPHID only when:

  • A user sets it explicitly with the web UI.
  • A user attaches a new diff (we copy the repositoryPHID, whether it exists or not, from the diff).

Ok fair enough.

Out of curiosity, what actually happens when a differential is associated with a repository? Is there any benefit in assigning old (closed) diffs to their corresponding repositories?

There's no significant benefit. It enables a handful of mostly-irrelevant things for older diffs:

  • Humans can read the field, which may be interesting or useful.
  • Herald can act on it at diff time (irrelevant for older stuff).
  • At some point, symbol lookup will get refactored so it cares about this field (hypothetical, irrelevant for older stuff).
  • Probably a few similar minor things I'm forgetting.