It's better than git-annex because it actually works on Windows. git-annex's Windows support is extremely clunky (see https://git-annex.branchable.com/todo/windows_support/) and automatically turns on direct mode (because Windows does not support symlinks without Administrator permissions).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 8 2015
(From a user point of view, at least?)
This is better than git-annex only because it works better on Windows?
Merged T5010 since git-lfs is a far more feasible option than git-fat from a technical perspective (regardless of whether the actual feature will be built into Phabricator).
Apr 7 2015
Apr 6 2015
Being able to grab the changeset-id/commit-hash while looking through repository history would be very useful. Currently I have to copy the link from the breadcrumb, paste into text editor, copy the changeset while avoiding the callsign. It's doable but having the plaintext available on the page, or a copy-to-clipboard (I don't think this can be done in pure javascript), would be nice to have.
Apr 2 2015
Apr 1 2015
Thanks!
You can do this with Herald. Here's an example which prevents anyone but me from pushing to "master" across several repositories:
Mar 31 2015
FWIW, most Go code likely encounters this issue since gofmt formats everything "correctly" (tabs to indent, spaces to align) with a tab width of 8. A single global setting would work perfectly for us (and anyone using Go).
Mar 30 2015
See also T7472.
Yeah, I vaguely remember there being a task.
We don't know if you'd be able to see them (vpn, policies). There is a task somewhere.
On an unrelated note... Is there a reason why {Fxxx} doesn't show the image content in emails?
It is terribly hidden.
Oh wow, I've never seen that before.
We should probably surface this better?
Mar 27 2015
I can reproduce the issue on a Mercurial repository hosted on Bitbucket: commit imported by Phabricator shows correctly UTF-8 in the diff, but not in the commit message. UTF-8 characters are handled without any issue with Git repos.
Closing for lack of feedback.
See T3353 for discussion of code vs text diffs.
I've identified that, at least for the diffs used for Maniphest task description changes, a significant part of the noise is caused by the 80 character line wrapping. Which seems to be applied to both old and new content *before* feeding it to the difference engine.
Mar 26 2015
Screenshot
Thanks again Evan, I can confirm this issue is fixed.
This should be resolved in HEAD. Sorry this took so long to address!
I've just run into this problem as well. This is really a showstopper issue, enough that I may need to abandon using Phabricator/Diffusion for my Subversion hosting.
Mar 25 2015
It's hard to wait, so I found my way to solve this problem.
Mar 24 2015
I've removed the two major sources of needless/expensive highlighting (D12132, D12141). There's a third that will eventually be resolved by T5501 (roughly, if APC settings are whack you'll run setup checks on every page, including setup checks against pygmentize).
I wanted largefiles support on my instance so I updated the patch file for the current version of Phabricator:
Mar 23 2015
Mar 22 2015
not sure if there is a technical reason not to.
Mar 21 2015
Great. Thanks for the fix
No, it appears that we can remove the flush() call with no general loss of functionality.
Gotcha. Need any more info from me for this?
We use nginx here, but Apache in the Phacility cluster and I use Apache locally, and I can't reproduce in either of those environments.
BTW, what server software are you running here? Ours is on Apache. I wonder if that might explain the difference.
Getting rid of the flush seems to fix it on it's own.
Okay. There are two relevant parts in that diff, both in src/aphront/sink/AphrontPHPHTTPSink.php:
Whoa, that was it!
I reverted and it works now!
Try reverting rP81d8898 with:
I'd be happy to help out there, though I may need a bit of handholding.
Is there any risk of us losing data due to rolling back to a previous schema?
All the Phabricator devs use Macs, and haven't seen this issue at least.
This is becoming more a pain for us because one of our devs is checking in from a Mac and there doesn't seem to be a client for OSX that doesn't hit a similar error.
I'll update again if he finds something that works. If anyone has any other suggestions, please let me know.
It seems like Phabricator wouldn't have much to do with the TLS connection closing early (which seems to be what some posts on the gnutls board would suggest cause this) but nothing else coincides with this breaking. I would think it would be an Apache thing, but it's a mystery at the moment.
Mar 20 2015
@chad I'm having the same issues after updating 2 days ago. What I find strange is that this is only an issue with phabricator. No issues with GitHub and there was no change to the git installed on the server (that worked fine so far). I checked to see if there are any permission issues with phd-user and vcs-user, but there are none.
To the new subscribers, are you also having issues? Do you have additional information to add?
Mar 19 2015
also maybe have a copy-hash-to-clipboard widget (requires flash?)
So the instructions on this page (adjusted for 1.9.1) fixed my problem: http://askubuntu.com/questions/186847/error-gnutls-handshake-falied-when-connecting-to-https-servers/187199#187199
I'm up to b7fa55ff93 btw
Ok, it looks like we're rejecting SSLv3 now. Still no success with git though.
I'll disable that now
Yeah, I'm not sure what's up. We're slightly ahead of you (rPb7fa55ff) but basically running the same code.
I'm assuming the current secure.phabrication.com install is at HEAD?
Hmm looks like that works fine too. Weird problem.
I changed it to require authentication, just in case that's the issue -- set a VCS password in Settings > VCS Password and try again?
That one worked.
Hmm, try this one?
Different one:
Cloning into 'www.pcwebshop.co.uk'... fatal: unable to access 'https://www.pcwebshop.co.uk/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
What error do you get if you try this?
Yep, that does work.
Try cloning this? Does that work?
It's not just pulls btw. Any git server operation (clone, fetch, push, etc) fails
That repo only supports ssh but I'm doing https. Can you enable https for it?
Can you test whatever you were trying to do on: https://secure.phabricator.com/diffusion/GITTEST/
It's git 1.9.1 distributed via Ubuntu package.
I saw some of those pages too and some people are saying that if you recompile with a different lib it makes that error go away but if it was that problem it seems odd that it would just start happening now.
What version of git are you using locally? and did you compile it?
Mar 18 2015
One more update on this. Sorry for spamming you guys.
Oh, and one other change I had made was enabling local file storage. I turned that off just to be sure and it's still broken.