Thanks for the quick fix! Just updated to latest HEAD and it works fine.

This should be fixed in HEAD. Thanks for the report!

3 main issues. ( Just my thoughts. Feel free to elaborate or ignore)

• It does not seem like audit.can-author-close-audit has any effect.
• The audit requestor should be able to close the audit regardless of the authorship of the commit
• I don't understand what the image below means. In this state, the commit still shows up under "needs audit"

Will give that a try. Thanks for the pointer.

There is a setting (default to false) for auditing your own commits. I don't know if that has any affect here.

Let's note this is not an oddball case:

Thank you very much! You solved all my problems :D

I believe this is fixed at head. Let us know if you're still seeing issues.

(And there are no configuration settings you can change which will possibly impact or resolve it -- it can only be resolved by an upstream fix to the problematic implementation.)

I have the same issue with SVN+SSH, but not with GIT+SSH. I used strace. This is the part where it breaks - looks like it breaks after the chdir call (in the middle of the snippet):

It is our mistake , it is the problem of my company internet. I try again,every thing is OK. Thank you every much !

Great, it works like a charm !

It's late...

The mercurial server is sending down capabilities which includes bundle2 at the beginning of the remote SSH during push (which tells the client it can use new bundle2). It's not sent as part of a command which the client invokes which is what T9450 is handling. Instead when the mercurial command server initializes it immediately sends over a list of capabilities.

I think I may see what the issue is. I believe the 'hello' command returns its list of capabilities, which is not filtered by T9450. I'm trying to test out some fixes but having difficulty with nano~

Specifically, the issue was that these commits contained strings like R2/R13, which the parser was getting confused about because of an improperly grouped regular expression.

This should be fixed by D15049. Thanks for the detailed reproduction instructions, including a repository I could clone locally.

I'm guessing this is still years (or decades) away on the road map, but we want to be able to run build agents in the us-west-2 region and our Phabricator cluster currently resides in ap-southeast-2. Having a way of replication repositories across AWS regions (by setting up Phabricator cluster instances in us-west-2 and having the repositories replicate over to them) would be very useful in terms of reducing our git clone times.

(I've made a private note about this elsewhere, if you work with @nipunn.)

The workflow I used when introducing linting was:

• Temporarily enable a large/default sent of rules, run with --everything and get the lay of the land, maybe make a list of common errors or get a list of all options from the linter itself
• Decided that rule X looked reasonable ("no trailing whitespace" or something like that)
• Send a diff out for review that fixed X and enabled the X linter rule
• Repeat.

@epriestley, Thanks, of course, adding any file to the next commit solves the problem.
By the way, it is a not a high priority bug since it does not broke the interface.

Thanks, those reproduction instructions are clear and I expect it will be straightforward for us to reproduce and fix this.

Initialization Error Pull of 'rMOBILE' failed: Command failed with error #1! COMMAND git clone --bare -- 'xxxxx' '/var/repo/MOBILE' STDOUT (empty) STDERR Cloning into bare repository '/var/repo/MOBILE'... /private/var/repo/MOBILE: Permission denied

I wonder why path "/var/repo/M/" is empty?

I have upgrade Phabricator to commit 473693786b86071f478b1490cf6bec5b4650dbea ,Wed Jan 13 . I have restart all webserver & daemons. When i relaod Diffusion page , appear these log

Re: LargeFiles Patch

Upgrade Phabricator to rP5592e59 or newer, then try again.

I've marked D14995 as fixing this, but only commits parsed after the upgrade will have author dates shown.

In T4705#61706, @ott-consult wrote:

Yes, this would really be a useful feature. Especially as CentOS still uses a 5.3 version of sshd and on production machines, I would like to keep the "normal" sshd on the standard port. Using a different ssh port for all other tools require a lot of extra config.