1853877 - mach try perf selects wrong base revision if branch is up to date with secondary remote

Status: NEW

(Testing :: Performance, defect, P2)

Description

[Jamie Nicol [:jnicol]]

I'm using git, and have two remotes: mozilla-unified via git-cinnabar, and my own github repo.

mach try perf selects the base revision here. This works okay as long as my local patches have not been pushed to any remote. However, if I have already pushed by patches to my github repo, then git rev-list HEAD --topo-order --boundary --not --remotes will return empty, and we end up using the current revision as the base revision.

I'm not sure exactly what the right solution is here, but here are a few thoughts:

• We should probably error, or at least warn the user if the calculated base revision is the same as the current revision. It took me quite a while to figure out that the wrong revision was being pushed, let alone why. I doubt anyone wants to push the same revision twice, and --single-run exists for a single revision.
• We could specify a remote to work around this, eg --remotes=origin. However, we cannot guarantee what the name of the correct remote to use is. Mine is actually called mozilla rather than origin.
• Perhaps we could figure the remote out from the current branch's upstream, though that of course only works if the user has configured that properly

Comment 1

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

I had the same issue today. When I checked git rev-list HEAD --topo-order --boundary --not --remotes it didn't output anything for me.

This is what I did locally:

git log --grep "1994034" # to find the hash of that commit
git checkout 71a99f8c272bfc0253db898105f5571f58dfb848
./mach try perf --alert 47222 --gecko-profile-threads "GeckoMain,Compositor,Renderer,Socket Thread"

I think the tricky thing is that I tried to run the ./mach try perf on an already landed commit. I think it makes it impossible to run ./mach try perf for commits like that.