Is there a way to disable this feature? Our security team has noticed that with this feature we can land code with just a single person's machine being compromised (we rely on an attacker needing two machines to deploy code as a safety mechanism). I.e. You make a revision, Foist it on someone, Approve it, then arc land it as the other person (saying y to the prompt).

In T3277#254315, @epriestley wrote:

grep -v master | grep -v '^[0-9a-f.]*$'

This part may prove slightly trickier to implement correctly in the general case.

+1 for this command. We have use a web-based UI for landing so our branches stick around locally. To fix this I'm currently using:

arc branches | grep ' Closed ' | sed 's/[^ ]* //' | sed 's/ .*//' | grep -v master | grep -v '^[0-9a-f.]*$' | xargs git br -D

fix lint

Thanks so much for fixing this!

Thanks for the heads up. Indeed this will break us (if I'm reading this right). .gitattributes is not required to be at the root level and we actually don't have one there, we put it in lots of subdirectories. Can you do a find or something like that? And not every one of our .gitattributes will contain lfs files so I guess you have to cat them all and return true if any have it?.

use repository api

• code review

Thanks for the code review and archeology! I did some archeology on our end and indeed, it was removed on Sep 26, 2018 when we forked this diff workflow for exactly the reason in this diff. With the --no-verify the LFS objects were not being pushed to our staging repo, so our Jenkins jobs wouldn't have them and would fail. So I do think this the right fix :)

• oops wrong way

Nice find! I see there is already a --no-verify in this upstream version but we didn't have it in ours... maybe because of the lfs version? So maybe this diff is actually improving the life of lfs folks?

• go with --no-verify

• Revert "only run fetch if git for-each-ref is empty"
• Revert "fix spelling"
• Revert "handle the case where you need to remove it before adding it"
• Revert "Use a named remote and branches for staging to help git-lfs"
• try the double push thing for lfs repos

Thanks Evan! I tried what you suggested but I think GIT_LFS_SKIP_SMUDGE=1 is only for pulling not pushing, since the first push in your suggestion is still uploading to LFS and their code doesn't seem to refer to that env var https://github.com/git-lfs/git-lfs/blob/5f969e6a3e48ecee48b6235adccc42a644e82101/commands/command_push.go, I can't really see any way to disable lfs other than git lfs uninstall; git push; git lfs install. Is that nuts?

• only run fetch if git for-each-ref is empty

• fix spelling

• handle the case where you need to remove it before adding it

try again with the remote removed from the failure before

try again now that I put in my ssh key

@epriestley is a t2.micro enough to handle phabricator for say 10 users (small startup)? What's the tipping point (concurrent requests I'm assuming not DB size for extra users)?

How did you fix this problem?

@epriestley I'm totally with you, we don't want any special casing for Facebook. I was just hoping others could benefit from this as well.