See also https://github.com/phacility/phabricator/issues/711. That report deals with reusing a callsign, and the new version of the repository picking up leftovers from the old repository.

We have such an option already, and it is on by default:

Does the cherry-pick not have "Differential Revision: ..." in the commit message?

It'd be nice if this could detect based on the commit content (hashing it), rather than explicitly only allowing one commit per accepted revision.

• It looks like DiffusionQueryPathsConduitAPIMethod has another hg manifest call, which we should switch over.
• We can leave the hg grep calls, per comment above.
• You could maybe refactor both hg manifest calls into a DiffusionLowLevelMercurialPathsQuery or something, possibly, if sharing the code otherwise is a pain.

We haven't seen other reports of this, and we don't have a plan of attack which seems likely to resolve this in a reasonable amount of time given that it's Chrome-specific and reproduction-resistant.

Let's make this check the state the revision had before we acted on it:

Closed by commit rPc1e8d97069fa.

Closed by commit rP6f246bd35190.

I think that plan ^^^ is a pretty good one, and this crops up somewhat-often.

◀ Merged tasks: T4988.

Is this still an issue after D9784?

I have about half a diff for this.

Fixing the bug is blocked by VCS binary version detection (T3046).

Are we at an impasse here? How can I contribute to this task?

Closed by commit rP05eb77c0a704.

Ah, thanks! I forgot we had this open. Yes, D10323 should fix this.

Wouldn't D10323 and rPfca8b5ab1b36 have fixed this issue?

Thats awesome, thanks guys! I had a cron job deleting these file hourly as well. Please let us know if the issue is indeed fixed with Evan's commit.

Cool. A possible first-degree approximation is checking if the files contain private key material -- I'm not sure if we ever did that. If they're empty, that's a smoking gun for this being the issue.

I'm still working through my backlog after a long vacation to Iceland, but I'll nuke the cron job I had cleaning out the test directory and see if we still see the behavior.

Closed by commit rPHU8695cdb1270b.

Closed by commit rPfca8b5ab1b36.

Closed by commit rPfca8b5ab1b36.

@wotte / @wassere, if you still see this locally, can you check if that fixed your issue?

Cool and fast! Thanks!

Oh, except that when you call a method on null we don't actually get an exception because PHP is sort of derp and everything just dies abruptly. This script reproduces the issue, at least potentially:

Although I would expect the temporary file to be destroyed even if the exception is raised. This is still a bug in any case, since we shouldn't write the file in the first place.

That's extremely helpful, thanks! I'll get that fixed up.

It could be related:

Thanks a lot for your help!

T5938 has a very similar issue on Git 1.8.5.5. I'm at a loss as to what's going on there, but hopefully the fix for this will fix both.

✘ Merged into T4946.

◀ Merged tasks: T5938.

Alright, I have no idea what's going on. This behavior is consistent with T4946, which is specific to Git 1.7.1, but you clearly don't have Git 1.7.1.

In T5938#19, @epriestley wrote:

Is that still running, or did it suddenly exit there?

Can you try this?

Is this a bug?

I've activated again and now it seems to be okay (Fully Imported).

Is that still running, or did it suddenly exit there?

The whole local directory of the repository was created by Phabricator. I just have used the UI. The shown git --version was from a terminal to the server.

I'd expect you to get an origin remote no matter what branches are present in the repository.

Did Phabricator clone this repository, or did you do it yourself?

Is it because develop is not the default on GitHub?

I also have edited the Default Branch to develop and the Track Only to master, develop before activating.

The repository exist, I've checked it manually with the same address, user and password.

Hm that's weird:

I expect the output to look like this:

Can you show me the output of this?

Ah sorry I forgot to mention:

Does git --version show 1.7.1?

arc commit also doesn't call diffusion.looksoon, but should.

Ah, thanks! I forgot we had this one already.

✘ Merged into T3498.

◀ Merged tasks: T5923.

◀ Merged tasks: T970.

We're adding a 1-up/unified view (see T2009) but don't plan to make this specific change outside of that.

This has come up a couple of times recently. Instead of supporting this as a security policy (which will be difficult to debug) I think we'll have an easier time of and get more milage from it by supporting it as a project membership rule (which, at a minimum, can have reasonable web UI workflows and be a lot easier to debug and understand).

The diffusion.looksoon call does this.

In T3102#18, @epriestley wrote:

• Implement Project/Repository relationships

I am also appeared the question，after when I upgrade the phabricator server.Is there a solution now?

See-Also: https://github.com/phacility/phabricator/issues/696

Closed by commit rPa5d24609748c.