Phabricator picking up downstream commits from Github forks of llvm-project?

Hi,

It looks like LLVM’s Phabricator started picking up downstream commits in Apple’s fork of llvm-project (github.com/apple/llvm-project), and is creating notification events about all the old downstream commits, e.g.

https://reviews.llvm.org/rG8910c5c786886f17a75bd142fa967932ca3f54c1

https://reviews.llvm.org/rGb03469c2d72621e1cccfeeaef719692600c075f4

This seems like a bug. Can this be disabled?

Thanks,
Alex

Someone pushed these changes to LLVM repo. See e.g.
https://github.com/llvm/llvm-project/commit/8910c5c78688

That appears to have been pushed to refs/am/changes/bbc4c751f01bb6f649942d3cf3b504a87c9019c8_swift/master-next

Does someone (perhaps someone from apple) know what that is? Was it pushed there, rather than the swift fork, by mistake?

Oh, this explains it! Unfortunately one of our engineers made a mistake, and pushed the ref to wrong remote while resolving a merge conflict on https://github.com/apple/llvm-project (pushed to https://github.com/llvm/llvm-project instead of https://github.com/apple/llvm-project). I just deleted the ref from the https://github.com/llvm/llvm-project. It’s weird that Phabricator decided to pick this up, since it’s not in the usual refs/heads namespace. Hopefully now it will stop going through those commits.

We will work on improving the process on our end to avoid mistakes like this in the future.

Thanks,
Alex

What's a good way to avoid these mistakes?

Sameer.

One way that I use to avoid accidentally pushing to the wrong repo, is to make sure that the "origin" remote (which is set as the upstream for the master branch, where pushes would go implicitly) is set up via an url that is (to me) read-only.

When dealing with github, I don't have a stored authenticated session for https, so to me, https://github.com/llvm/llvm-project is read-only (or, if I try to push there, it'd prompt me for username/password, which I'd notice). When pushing to github, I use ssh as transport, with urls like git@github.com:llvm/llvm-project, and add this as a separate remote that I only use for pushing. That forces me to explicitly spell out e.g. "git push <read-write-remote-name> master" to push there.

If access to github via https is authenticated already, one can choose to set the origin remote to a git://github.com/llvm/llvm-project url instead, which always is read only.

None of this helps against accidentally doing "git push <accidentally wrong remote name> <other branch>" though.

// Martin

Oh, this explains it! Unfortunately one of our engineers made a mistake, and pushed the ref to
wrong remote while resolving a merge conflict on GitHub - apple/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This fork is used to manage Apple’s stable releases of Clang as well as support the Swift project. (pushed to
https://github.com/llvm/llvm-project instead of GitHub - apple/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This fork is used to manage Apple’s stable releases of Clang as well as support the Swift project.). I just
deleted the ref from the https://github.com/llvm/llvm-project. It's weird that Phabricator decided
to pick this up, since it's not in the usual refs/heads namespace. Hopefully now it will stop going
through those commits.

We will work on improving the process on our end to avoid mistakes like this in the future.

What's a good way to avoid these mistakes?

One way that I use to avoid accidentally pushing to the wrong repo, is to make sure that the "origin" remote (which is set as the upstream for the master branch, where pushes would go implicitly) is set up via an url that is (to me) read-only.

When dealing with github, I don't have a stored authenticated session for https, so to me, https://github.com/llvm/llvm-project is read-only (or, if I try to push there, it'd prompt me for username/password, which I'd notice). When pushing to github, I use ssh as transport, with urls like git@github.com:llvm/llvm-project, and add this as a separate remote that I only use for pushing. That forces me to explicitly spell out e.g. "git push <read-write-remote-name> master" to push there.

If access to github via https is authenticated already, one can choose to set the origin remote to a git://github.com/llvm/llvm-project url instead, which always is read only.

Having origin be read-only and using another remote for pushing is a good idea.
The other recommendation I have is to always explicitly specify the remote and
the source and destination branches when pushing e.g.

git push origin master:master

or if you are using a separate remote for github as recommended above:

git push llvm-github master:master

This way it is always clear exactly what and where you are pushing. It
seems like the a lot of the issues we've had so far with people pushing
extra tags and refs is that they are using `git push` with no arguments
and the default configuration is pushing things that aren't expected.

-Tom

FYI, the following configuration option is useful:

git config --global push.default nothing

It forces one to always be explicit when using git-push.