The new two columns layout is really neat! Any plan on having the second column move along as one scrolls down?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 5 2016
Ok this has been removed now.
whoopsies
Yeah, that claim assumes someone will arc diff some published commit sooner or later (i.e., run arc diff while on master with no local changes). While this wouldn't happen on a normal workflow or on purpose, I suspect it happens more-often-than-never.
From what I see, this doesn't actually normalize over time, if the staging repo is used only for staging: none of the /diff/ refs will ever be a parent of master from the real repo, because of the rebase during arc-land (I've written this at some point in Manual Staging Area Caveat).
Mar 4 2016
I think that'll fix it. Thanks for the report!
I can't recall any reports of those issues on other installs, and we haven't experienced them ourselves. I don't think these issues are typical, frequent, or widespread.
@epriestley I think that's a massive underestimation of the prevalence of the Atom editor. It has a pretty large user base.
Ah, I see. Well, that's one more way to solve it, I suppose. At the same time, it might be slightly less efficient if you have to do that on 20-30 objects in one session, and then edit. The hammer method would be one command and one login, and then you can edit all of the above (including policy, via normal web interface means.)
(That's a theoretical workflow, it's not there yet)
Hm, somehow I missed the documentation on that. However, set-policy does not work on all objects.
How many of these would be solved with a ./bin/policy set-edit-policy --user bobc object, instead of unlock (== 'all users') ?
Added several scenario issues to the description. I don't know that I can track down all the comments, as this place is huge and my memory is pretty shaky on things like that. I just remember a observing few different conversations regarding it, but I cannot remember where. If we polled users, we could probably get a better idea of whether this matters to users in general.
Didn't see that ticket but just read over this and that would be what I would need. I think I am also seeing a very rare edge case as the specific issue I am seeing every day or so is that git clean -ffxd fails with warning: failed to remove /something but every time I go in to look around after everything looks completely normal and then running git clean -ffxd runs successfully.
Perfect!
Quick update here ahead of deployment tomorrow:
What are the specific things you want this feature for? Please describe the root problem you're facing. See Describing Root Problems for help.
we have a project that I am a member of that we are using to ensure that one of our "owners" approves the cl. We do this by using herald to automatically add that project to the reviewers. The project is a blocking reviewer.
I have the same problem, I installed the following 's jenkins plugin for phabricator :
https://wiki.jenkins-ci.org/display/JENKINS/Phabricator+Differential+Plugin
But this plugin is unusabled because of this issue. every time I try to run a build on a branch that contains a binary file modification (rhe most often .mo file)
th arc patch command crashes. Are you going to fix this issue soon, please?
@paladox: Your last question was already answered before in T8612#163215
@swisspol, the duplicate bug is already fixed by rP58cea0714bff
If there aren't docs yet, anyone willing to speak quickly on what elasticsearch integration entails?
Mar 3 2016
Given how frequently ANSI characters and similar occur in build logs, this probably doesn't make sense until after we have support for binary data on the API (T5955).
Upstream builds have been in production for some time. There's always more work to be done, but I don't think there's anything actionable left here that isn't covered elswhere.
Is the outcome of this task likely to be select a source for a given project where source might be manual, or ldap, or something custom?
Is the outcome of this task likely to be select a source for a given project where source might be manual, or ldap, or something custom?
Would it be possible for the source to not only serve as an adapter but also create/remove projects on-demand?
Oh ok, is there a way to set it to unlimited so that a user can choose to do it per file but yes it is unlikely a user will review a million changes but it is always good to check.
You can manually adjust the $hard_limit in your local installation here: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/diffusion/controller/DiffusionCommitController.php;ac729278328ed9679229d11ba1eefdad784b59e2$148
I don't intend to change that limit. I believe there is very little value in reviewing 1000+ file changes from the web UI, and that the 1K file limit is a reasonable one.
Yes that's what I would like to see please, please allow it to show that over large commits please.
./bin/search index --force --all fixed this,.but i'm confused how some random tasks weren't indexed and some were
That commit is changing more than 1,000 files.
@epriestley oh because on https://phabricator.wikimedia.org/rAPAW76c6444cfb64e872b8b15688a8999d96af84a406 it dosent do that yet it is only chaning a 100 files.
In T8612#163197, @paladox wrote:What about per file diff viewing it would hide them by default but add an option to each file that says show diff.
In T8612#163196, @aklapper wrote:In T8612#163189, @paladox wrote:Please could you add do something like hide huge changes by default and add a button that will let you see the change please.
Please not, as that already exists. See ""Download Raw Diff"" in the upper right corner of the link you provided.
In T8612#163189, @paladox wrote:Please could you add do something like hide huge changes by default and add a button that will let you see the change please.
@chad no but gitblit can also be a application, https://github.com/gitblit/gitblit its built on java. https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCentralAuth.git
Yes there that but if you are on a fast server then that time will be reduced, what about allowing to view per file diff meaning that all of it is hiden but having a user select per file diff that would improve everything and allow for loading quick.
@paladox isn't gitblit a desktop application?
@paladox Not sure the benefit of giving the user a button that takes 19 hours to load.
Hi viewing a diff here https://phabricator.wikimedia.org/rAPAW76c6444cfb64e872b8b15688a8999d96af84a406 causes no diff to show because it is too big.
BTW I realized I forgot to specify in the description of the task that what I'd like to know is why do the logs look like this and what is error 28? Does this come from Phabricator? Is there a lower-level log one could look at?
Actually all build plans show these duplicate steps. Is this an (unrelated) bug?