my system is mac OS X ,php is 5.5.3

What operating system and what PHP version are you running are very basic system administrator questions. If you're not able to answer them, I don't think we'll be able to help you further and you should find a hosting site like Phacility to run Phabricator for you.

I install ph server in linux env, the ph server repo pull from remote git repo is no problem thanks any one

You're getting PHP segmentation faults. What OS/PHP are you running?

looked the output log ,the ph server is did the work for pull the repo of us(my git reop)
the ph server us repo the status is follow :

Type Git Callsign US Projects None Status
Repository Active	
Found Binary git	/usr/bin/git
Pull Daemon Running	
Task Daemon Running	
Storage Directory OK	/var/repo
Initializing Working Copy	Daemons are initializing the working copy

I install git-core ,add git-http-backend to /usr/bin dir,and redo the command of '/repository update US --trace'
the output log is follow

>>> [9] <query> INSERT INTO `repository_statusmessage`
          (repositoryID, statusType, statusCode, parameters, epoch)
          VALUES (8, 'init', 'working', '{\"message\":\"Creating a new working copy for repository \'US\'.\"}', 1446433333)
          ON DUPLICATE KEY UPDATE
            statusCode = VALUES(statusCode),
            parameters = VALUES(parameters),
            epoch = VALUES(epoch)
<<< [9] <query> 2,103 us
>>> [10] <connect> phabricator_passphrase
<<< [10] <connect> 478 us
>>> [11] <query> SELECT * FROM `passphrase_credential`   WHERE (phid IN ('PHID-CDTL-ktdk77skbcx53aaew7bk'))   ORDER BY `id` DESC
<<< [11] <query> 338 us
>>> [12] <query> SELECT * FROM `passphrase_secret` WHERE id IN (2)
<<< [12] <query> 296 us
>>> [13] <exec> $ git clone --bare -- 'xxxxx' '/var/repo/US'
[1]    79645 segmentation fault  ./bin/repository update US --trace

I'm a contributor, and I know much of the code.

Are you a user or developer of Phabricator?
Actually there three ways to create a repo in Phabricator (let's talk about only git repo).

• Create a New Hosted Repository Create a new, empty repository which Phabricator will host.
• Import an Existing External Repository Import a repository hosted somewhere else, like GitHub, Bitbucket, or your organization's existing servers. Phabricator will read changes from the repository but will not host or manage it. The authoritative master version of the repository will stay where it is now.
• Import an Existing External Repository and at the same time Create a New Hosted Repository for it. This means import a repository hosted somewhere else, like GitHub, Bitbucket, or your organization's existing servers. Then create a new, repository (based on the import source) which Phabricator will host.

Phabricator repositories work in one of two modes:

• Import an Existing External Repository

Phabricator will look at the external repository, and will run git fetch every once in a while. Users will use git push and git pull to/from wherever the External repository is.

• Host Repository on Phabricator

Phabricator will not look anywhere for the repository, and never run git fetch.
Users run git push and git pull to/from Phabricator.

actually it's not true:-) it IS possible to import it Phabricator's diffusion a git repo and host it inside. since i already did it many time. sometimes it's working sometimes it's not (with the same source and the same repo).
actually i do some more debugging.

• if i import it with " Start Import Now" in stead of "Configure More Options First" which means no hosting ie.: Host Repository Elsewhere. then it's works and can import the repo perfectly. so the only problem is in case of hosting repo. it'd be useful to some kind of log what kind of git command was used, what kind of return value was used etc.
• from now on i'm no longer be able to import the repo with hosting again properly. but if i start with a fresh install of Phabricator (ie totally new database and everything else) then it's works again until i delete the first imported repo.

• Host Repository on Phabricator

@Gavin, on debian you should :

• install git-core (git is not enough)
• verify that git-http-backend exists in /usr/lib/git-core/git-http-backend
• make a link to something in your path (in my case /usr/bin)

I do the command of '$ /usr/local/opensource/phabricator/bin/repository update API --trace', the api repo status is changed ,see follow

Type Git Callsign API Clone/Checkout As ufish-server/ Projects
ufish-server
Status
Repository Active	
Found Binary git	/usr/bin/git
Missing Binary git-http-backend	Unable to find this binary in the webserver's PATH. You may need to configure environment.append-paths.
Pull Daemon Running	
Task Daemon Running	
Storage Directory OK	/var/repo
Working Copy OK	/var/repo/API/
Waiting For Update	Waiting for daemons to read updates.
Importing	0.00% Complete

ph remote repo need git-http-backend support ,but i not found the git-http-backend thanks

Does GIT_CURL_VERBOSE=1 git clone http://phabricator.local/diffusion/TEST/test.gitdoesn't give you useful informations ?

Can you show me the output of this command?

my system is mac os ,also the daemon process communicate with ph server is normal ,the ph server is aways found daemon process is dead

Interesting read regarding GitHib's usage of Git LFS: https://medium.com/@megastep/github-s-large-file-storage-is-no-panacea-for-open-source-quite-the-opposite-12c0e16a9a91#.310ve89hz

I would like to mention here that on October 1st git lfs reached v1.0 as announced in this article.

I assume this was either solved, or the user gave up; Closing.

One last test - changing the server Mercurial version to 2.6.2 resolved this issue. I also tried commenting out this line (and restarting services):
https://secure.phabricator.com/diffusion/P/browse/master/src/applications/diffusion/query/lowlevel/DiffusionLowLevelMercurialPathsQuery.php;cea633f698daad27d5e2b781124198d9f0767878$31

Ugh so I can reproduce this regularly on the one repository I have (with fresh commits following steps to reproduce), but I tried creating a new repository to test in and I can't reproduce it there. I'm not sure what happened to the repository I see this in.

No, this was surprising, and surprises are bad. If it could alert the user
and say "whoa there, it looks like this diff was updated while you were
commenting," that would be good -- but this was literally the exact minute.
My coworker and I were submitting within seconds of eachother. This is
definitely an edge case.

Cool, glad to hear it! This is, at the very least, something we could document better. I don't think the documentation currently mentions that inlines are even a thing, much less describes the porting behavior or the rationale for it.

My previous employer was a 100%-on-github shop. This employer is a nearly-100%-on-phabricator shop. I will tell you I am entirely a phabricator convert. I've been using github and singing its praises for years and the last six months I've been using phabricator have been eye-opening. I love this software. :)

This feature is always going to be imperfect, but my personal experience, at least, is that something like 80-90% of inlines port somewhere reasonable (the code is still the same, or nearly the same), and I understand about half of the rest of them from context, and can click the "Rewind" button for the remaining few to see what the author was talking about if I don't remember. There are also cases where we can improve the behavior without needing to solve any hard AI problems, see T7870 for the ones we know about (it's possible that whatever you hit here is a case we could improve).

In T9628#141693, @epriestley wrote:

Okay, I think what you're seeing is an inline which has been ported forward. This is a feature, and an expected behavior. Here's an example of what it looks like.

So for example, if i were to go make some changes to D14333 and wait to submit those changes, and you were to comment on it, those comments would be largely meaningless after.

Okay, I think what you're seeing is an inline which has been ported forward. This is a feature, and an expected behavior. Here's an example of what it looks like.

Oh, wait, re-reading your comment. No, I can't share the exact screenshots because it's our source, and that's proprietary. But when I commented on line 58 of the diff, and then the diff was updated as I submitted, that line actually became line 78 or whatever, and so the comment is still there on 58 or whichever, and makes no sense anymore, so the "review" of my comments on that diff are now entirely confusing and not helpful.

The comments were pinned to line numbers, and when the diff was updated, the line numbers changed, and so the comments became meaningless. This was really a problem because the diff changed substantially and the comments were important to those lines, rather than the specific files.

Yes, that is exactly what I was expecting to see. I had just now gotten a diff created. :)

Maybe it's easier if I try to follow your instructions. Here's what I did:

I am having trouble configuring arcanist to work against this phabricator vs my "home" phabricator. Otherwise I am ready to do this.

i am not sure it works if all of those things happen with me as the sole actor.

so let's start with this revision. to reproduce, i would need to create a diff on that, and then comment on it, and while i had a session with those comments "in the air" in the web, have that diff updated, and then submit my comments.

yep, doing so now.

You can probably use rGITTEST, but just copy/pasting some random diffs into the web UI is likely sufficient in this case too (no special behavior around inlines should get triggered). You're recent enough locally that you shouldn't run into any compatibility issues.

So I just want to add a little bit more context here:

Sure, let me see if I can do that, I'm heading in to the office now.

In particular, inlines are bound to the exact diff they are left on ("line 17 of changeset 28942 on diff 1842"), not a mutable location like "line 17 on file x/y.c on the most recent diff of revision 293". For example, you can go make comments on older diffs, which would not be possible if we didn't bind them to specific changesets.

This is not T4768.

Actually.... Rereading, maaaaaaaybe it's the same? It would have to depend
on how the back end actually managed those revisions. If phriction treats a
wiki update the same way diffusion treats a differential update then yeah,
this is our bug.

Oh god, that's it. This has been around since 2014? :(

I think it's T4768: Phabricator silently overwrites concurrent changes (no conflict detection)?

The SSH stuff should work fine. I don't anticipate supporting the HTTP stuff.

I know of at least one open source project that is planning to use this heavily, so in order to keep my fork on my phabricator instance (instead of moving it to GitHub where the original is based), phabricator will need to support LFS.

Gitlab is also planning to support Git LFS:
https://about.gitlab.com/2015/08/13/towards-a-production-quality-open-source-git-lfs-server/

+1. It would be great to show the audit status before every referenced commit within a task, in order to improve the efficiency of code reviews.

Ah

As a minor technical point, you're trying to create imported repositories (i.e., import repositories from GitHub), not hosted repositories, right? This endpoint can't create hosted repositories at all, AFAIK.

I don't think that would impact the outcome here. ssh-auth would still fail: I believe the problem is that php is in /usr/local/bin (or maybe /usr/games), so ssh-auth can't execute without that in path.

This endpoint is very old and has a lot of problems, including not being cluster-aware. In the Phacility cluster, the web host and repository hosts are separated. repository.create can not create cluster-aware repositories.

FWIW, my intended use case is to consume GitHub's organizations feed and automatically mirror repositories in Phabricator.

I deployed rP4c1463eb to this server and the reproduction steps above now work correctly, so I think D14311 fixed things. Let us know if I missed anything.

Thanks, that's very helpful.

For example:

Ah thanks for the fix! I was going to try taking a swing at this soon, but I'll keep in mind about policy-related things and noise.

The Mercurial upstream fixed this but we need to retain the (1 or 2) or (3 or 4) code for backward compatibility anyway, so I don't plan to remove it until we run into a real problem it causes other than "it is icky".

I don't remember what the original context was here, but T9319 is likely a reasonable proxy for it.

This does not appear to describe a reproducible issue. See:

See also T4245.

Subversion does not have top-level branches or tags; these features are purely conventional.

• rCALLSIGN autocompletes.
  • r substring, where "substring" is a substring of the repository name, jumps to matching results.