Page MenuHomePhabricator

When landing, it might be nice if arcanist could check if changes are being pushed to the canonical git repository
Closed, WontfixPublic

Description

Context

For the project I'm working on, I'm using a build system called Yocto. 10,000 foot overview:

Yocto builds things by interpreting recipes. These recipes can specify a git repository as the source of a particular software package. If the source is a git repository, it creates a local 'mirror' of the repository, then clones a working copy from that mirror.

Problem

Let's say I go into that working copy, do some development (arc feature, edit, arc diff), then eventually get the revision accepted and arc land it, it lands successfully. Or so you think. Since the working copy is cloned from this asinine local mirror, the change was pushed to that master instead of the real, canonical repository.

This has lead to quite a lot of confusion around here. Not only with changes not being pushed to the repository, but also if that local mirror is slightly out of date, there are some weird conflicts that can happen when you finally go to actually land the thing.

Issues

  1. First, it would be nice if Arcanist could either:
    • Issue a warning that you are attempting to land to the non-canonical repository. Possibly, it could refuse to land.
    • Either set origin to the canonical repository or add a new remote to the canonical repository and push to that.
  2. Second, it would be nice if the revision is closed in Differential but no commit has appeared in the appropriate repository, it would report as "blocking others"

Solution Approach

I'm not going to kid myself that this is anything other than a corner case of accidental complexity, and that I'll probably have to scratch this itch myself. Before I start slogging through code, I'd like to get some feedback on the best approach. I think fixing the second issue is beyond my 'occasional casual phabricator hacker' skill set. I think I can probably tackle the first, however.

  1. First, not everyone will desire this behavior, I'd imagine. We'll need to explicitly enable it. This could take the form of a command line option. Problem there is I don't want to have to specify that every single time. I'd imagine that a good place to configure this would be the .arcconfig file.
  2. Second, we'll need to somehow determine what that canonical URL should be. We could either:
    • Encode this explicitly in the configuration mentioned in the first item. This is probably easiest.
    • Make a conduit query to get the url from Differential. I don't know if such a conduit API exists.

If we go with the easy option outlined above, I'd imagine that an appropriate .arcconfig file would look like this:

{
  "conduit_uri" : "https://phab.example.edu/"
  "canonical_repository" : "ssh://git@phab.face.isis.vanderbilt.edu/diffusion/KERN/kernel-goose.git"
}

If the canonical_repository is present, the arc land process would be modified to compare the origin address against that canonical URL. Depending on the behavior we decide upon, it would either issue a error diagnostic, or under the covers try to reset the origin.

Problems I Haven't Thought About

  1. I haven't thought about how this would impact Subversion. First, we're not using Subversion for anything built by Yocto. Second, I don't know if this problem exists in my use case. I don't think this is a real problem because Subversion is centralized. Perhaps I could have checked out a working copy from a svn:// URL, and need to use a https:// url to actually commit, but in that case, the land would fail. We could suggest an appropriate svn relocate command.
  2. I know less than nothing about mercurial.

Related Objects

Event Timeline

wotte claimed this task.
wotte raised the priority of this task from to Wishlist.
wotte updated the task description. (Show Details)
wotte added a project: Arcanist.
wotte added subscribers: wotte, epriestley.
thormuller moved this task from In Progress to Backlog on the Arcanist board.

This hasn't come up again, so it looks like it probably isn't a feature that would see a lot of general use.

I'd also say this is probably a bug/issue primarily in Yocto: it probably shouldn't allow pushes to local mirrors? To the degree that this is a Yocto problem, I'd prefer not to solve it in Phabricator (see T13229).

As a possible workaround, arc land has had an explicit --remote for a while now. You could conceivably use arc land --remote actual-good-upstream as a partial approach here. Some future version of arc might let you specify arc.land.remote.default, although I'd like stronger use cases before pursuing that.