Kicking this out of Differential because this is reproducible in every application that allows you to edit comments.

it's a "fresh" repo, created yesterday, with no commits. I immediately
disabled those upon creation and then circled back the next day considering
it "completely new"

How did you disable this option in a newly created Git repository without realizing you had made the change?

ah. yes. I turned those off.

This should be resolved by T12049 + T11114, once Differential moves to the new comment area UI. The new universal haunted mode puts a spacer into the document while the panel is haunted, so if the panel is 500px tall we put a 500px empty space at the bottom of the document. This means that all content is always visible while scrolling.

I can't immediately reproduce this.

Although this wording is a little unclear, commandeering makes you the author. A more precise wording would be something like "The current author for this revision is X. It was created on Y." but that's clunky and only smooths out this particular case.

I have no idea how to reproduce this error. I'd guess something along the lines of take a new version of Phabricator and apply an old upgrade script, but that's really just a guess.

After D17103, at HEAD of master:

Thanks I made the smtp-encoding change. We're just about ready to update to a vanilla install. If it doesn't fix it and I can provide reproducible steps, I'll update this bug report.

Hmm, I don't see that one in the upstream either. Maybe your origin is also a fork?

We're running a fork and sorry, I know it's a little behind stable. We're working on getting back to a vanilla install to make updates easier.

$ git merge-base HEAD origin/master
33bf2a79def2e03c2248730afa080ead489942be

What does this show, when run in your local working copy?

My workaround for arcanist:

I had a look at other bug reports. It looks like I am not the only one having this kind of problems. So it seems that hg >= 4.x is not supported yet, and actually not even the whole 3.x is supported.

@gabe - That's the same issue, I believe. You should be able to push using Mercurial 3.4. I've been meaning to do some testing to try and fix this over the winter break but a day is no longer what it used to be.

Not sure if this is the same issue, this is on a new phacility hosted phabricator instance, when attempting to push to a new mercurial repo:

Thanks, I think D17097 should fix this. It isn't intended, and is just a curious artifact of some other behaviors.

I strongly suspect this report has enough information to let us replicate the issue locally, so you don't need to take any further action yet. I'll follow up if I have difficulty replicating it and we can figure out what differs between my synthetic test case and your real environment.

Reference in PHP 7.1 migration guide: http://php.net/manual/en/migration71.new-features.php#migration71.new-features.asynchronous-signal-handling

It will likely be easiest to replicate again after upgrading to Week 52 stable this Friday, since I can't use precise same diff, and don't know the precise set of replication criteria yet.

You can always create a test instance in Phacility, and upload the diff there - those are free and temporary - see Reproduction/Resources
There's also rGITTEST, although maybe it's not so good for a super huge diff...

We weren't running quite HEAD then, but we were running a version that was our patches on top of something about a week old -- see the end of the description of T11743, which was the first report in that chain. Our version today is a couple of months old, so I see why that'd feel different.

Hm; we weren't running HEAD when we reported T11748. We have an upgrade planned to latest-stable in a week or so -- will that be sufficient to re-test with? Or is there a repository that we can apply a 4,800-file diff to on Phacility?

Please update to HEAD before filing a bug report. We can't take reports against old versions of Phabricator. You can use Phacility if you'd like to test an up to date installation.

(2) and (3) are correct.

I've been playing with it for maybe half an hour, and couldn't reproduce:

• Made revision public
• stopped the daemons
• mention a user
• updated the revision to a new diff
• made the revision not-visible to that user (visible only to the acting user)
• start daemons and let them finish the queue

Thanks for the advice. That yields the trace below. My understanding is that it was a diff with policy set to subscribers which had an author plus a single subscriber. That subscriber was added by herald upon the diff's creation, so there's certainly grounds for something going on there. I had trouble divining the exact issue, but tinkering with the permissions for the object ended up letting the emails go through.

We used to have a tool to show a task's data, but it must have gotten lost in some refactoring.

• In Daemons, find the task ID in the leftmost column of "Leased Tasks".
• Run bin/worker execute --id <id> --trace to execute the task in the foreground.

That will give you a more detailed error information which you can paste here.

Just updated to head and am seeing the same issues.

I know it's closed, but here are few proposals (not sure if better in any way):

• base
• derived / derivative

cat is slow to appear

I see cat :)

ok now cat is in feed

hmm, cat no show in feed

It's doing it again now...

It's currently unclear to me if this is a bug report or feature request. The code appears to be working as intended, and adding the description to the property table would be an added feature.

Please follow all guidelines in Contributing Bug Reports. These are required on all bug reports.

This isn't a valid bug report (for example, it is missing reproduction instructions). Please see Contributing Bug Reports for help writing bug reports we can accept upstream.

Tested. master branch working . thanks.

(the revision number is in ` because I got an exception trying to attach the mention, I guess)

I think the major intent was being able to edit "View Policy" so you could create private documentation, but I don't recall if we got that far.

You could tag a project I think, but not sure what that actually did.

Basically nobody is using Diviner, and I don't think the "Edit Book" page actually does anything useful.