Page MenuHomePhabricator

Differential advanced search: bucket/group by repository
Closed, WontfixPublic

Description

Root problem: you search the diff of a group of persons (e.g. GSoC students) committing to several repositiories, you want to see what reviews are still open, and where they contribute.

Suggested solution: Differential advanced search > allow to bucket/group by repository

Event Timeline

How does grouping by repository solve that problem?

Like, is "Students" a repository and not a project? Can you put "Students" into a project and filter open results that way? Where do repositories come into play?

You can also already filter by repository. Why do you need to group by repository?

The goal is to sort the contributions of one person who committed to a lot of different repositories, to get an overview of where they contribute. For example, that allows me to identify what repos are on my expertise domain so I can review there / who I can contact to unblock situations for other repos.

At Wikimedia for example, we have 1500+ repositories. It's not really convenient to try to guess what repositories a new contributor will target.

Would having the repository on the "card" solve the issue, albeit not as perfectly? My guess is for instances that 1.5k+ repositories, always knowing the repository on a diff card is likely useful, where just bucket queries are likely narrowly useful.

Aye, that would allow to visually scan the cards, and to understand what repo is concerned by each change.

... but I would be very happy to get just the repo on the card now, if we can upstream it until T418.

eadler added a project: Restricted Project.Jul 7 2016, 5:19 PM

If bucketing is really what you're after, you can have it by just dumping this in your extensions:

DifferentialRevisionBucketByRepository.php
<?php

final class DifferentialRevisionBucketByRepository
  extends DifferentialRevisionResultBucket {

  const BUCKETKEY = 'repository';

  public function getResultBucketName() {
    return pht('Bucket by Repository');
  }

  protected function buildResultGroups(
    PhabricatorSavedQuery $query,
    array $objects) {

    $viewer = $this->getViewer();
    $grouped = mgroup($objects, 'getRepositoryPHID');

    $groups = array();
    foreach($grouped as $repo => $revisions) {
      if (!$repo) {
        $name = 'No Repository';
        $repo = 'null';
      } else {
        $name = $viewer->renderHandle($repo);
      }

      $groups[] = $this->newGroup()
        ->setName($name)
        ->setKey($repo)
        ->setObjects($revisions);
    }
    return $groups;
  }
}

But the resulting UI is a little poor if you have more than maybe a dozen revisions in the results, and there's no (?) way to join this with the "Action Required" bucketing so I don't think it's really worth it.

epriestley claimed this task.

I don't think this meets the high bar required by modern feature requests (see "Upstreamable Feautures" in Planning).