Open-source developer working for Collabora.
- User Since
- Jan 28 2015, 3:48 PM (461 w, 3 d)
Jun 12 2018
@epriestley Noticed you'd been doing proximate work; I'm not planning to push this further forward, so please feel free to commandeer this revision.
Aug 15 2017
Aug 8 2017
May 11 2017
Apr 24 2017
@epriestley Thanks so much for the detailed guidance! Sorry that my turnaround time hasn't quite justified the work you put into this: my time slots are quite fleeting, as I only pretend to be a web guy from time to time.
Apr 2 2017
Apr 1 2017
Per commit message, this is not at all suitable for merging in its current form.
moar staging area
Mar 29 2017
Mar 7 2017
Jan 13 2017
Dec 19 2016
Dec 7 2016
Dec 2 2016
@epriestley Thanks, that's fixed it! I'd not looked index engines at all before, so wasn't sure if I was just missing something stupid on that side.
Dec 1 2016
OK, this is interesting: having tried reproducing it on a test Phacility instance, it works as expected there. Perhaps one difference is that my local installations don't have Diffusion serving repositories itself over, e.g., SSH? These repositories do not have any URIs other than a remote Git URI which Diffusion is observing.
Oct 7 2016
Oct 4 2016
Oct 3 2016
Yep, my bad: I'd fixed it behind that commit, spotted the commits ahead before the rebase, but wasn't actually testing what I thought I was, so thought it was still there in master. (And sorry for the delay, was out all last week.)
Sep 21 2016
Sep 20 2016
[third time's a charm ...]
[no change, just pushing to staging]
Aug 16 2016
@epriestley Here's an anonymised version of a live workboard. I've completely wiped out all identifying data; I thought about summarising the task titles rather than obliterating them, but afraid I lost the will to live at some point.
Aug 10 2016
Aug 9 2016
@epriestley Is there a pathway for reading (not writing) edges which would be open to community contribution? Having arc patch Tnnnn functionality, pulling all the revisions attached to a particular task, would be really attractive for us as we tend to have a larger number of revisions per task.
Aug 5 2016
Also be careful that the 'Depends on:' commit message parsing is strictly additive; if you ever change patch order in any way, your dependencies will get out of whack. If you're doing this, you can modify DifferentialTransactionEditor to reset the dependencies before parsing, but this means you throw away any dependencies manually added through the web UI.
Aug 3 2016
arc amend now succeeds, overriding the global config.
arc amend now works, overriding the global history.immutable configuration.
Unlike previously, this results in arc amend succeeding, rather than complaining.
@avivey Reasonable enough. I'd hoped to be able to use socket paths explicitly, but that would be a separate change to this then. Thanks, and sorry for the noise.
Aug 1 2016
@avivey: Is there any particular rationale to doing this? I'm looking at going in the other direction - completely away from TCP - and this makes that somewhat harder ...
Jul 27 2016
@epriestley Yeah, that would certainly be really useful for some cases; I imagine infrastructurally it'd be a good step towards this as well, along with T10569. I don't think it would help this particular usecase though.
Jul 26 2016
Jul 22 2016
@epriestley Because it allows the reader of this report to reproduce the underlying issue without cloning anything or clobbering their .arcrc. Here are some less contrived scenarios, which are not mutually exclusive:
- the user makes a typo (project lacking .arcconfig, or trying to use Phabricator for the first time themselves)
- the .arcconfig comes from a time before Let's Encrypt (e.g. if you're in the middle of a git bisect that takes you back some distance)
- the admin is just attempting to migrate people to more secure services and does not expect that services will fail (or at least not fail in such an opaque and confusing manner) in the face of a redirect
May 20 2016
@benjumanji history.immutable does not actually cover it, but this task is probably the wrong place to begin that entire discussion again.
May 4 2016
@cspeckmim Right, that was an edge case indeed, but even very active tasks can rapidly pick up a huge number of subscribers/tokens/etc (something I'm seeing on my install). I'd personally aim for a collapsed-but-expandable '[+] 16 users subscribed, 7 tokens awarded', but this is definitely getting deep into design territory.
Apr 29 2016
@epriestley Thanks for the thorough response. I guess it's probably been fixed in intermediate revisions, and as you say, it is all changing pretty dramatically anyway, so no big deal: as it was a newly-created repository, I just scrapped it and created anew.
Apr 28 2016
Now, I do agree with you this interaction is imperfect and could be improved, and your feedback is duly noted, but we're a team of 2 here with 1500 tasks open, so some things are just be imperfect until next time we're in the product.
@chad 'No points' or simply showing nothing is less information. An incomplete word isn't a deliberate choice to show less information, it's how it happened to land. Anyway, seems like you consider it a feature, so I'll leave it alo
@chad If the verbosity is essential, perhaps it should be word-wrapped in the collapsed case, rather than truncated?
@chad OK, fair enough; I guess just close this and I'll build something locally.
When you have the side project profile panels collapsed, then go to create a new milestone, it will have no tasks. The profile panel then shows 'This milestone has no tasks yet', but brutally cut off to 'This mileston-' in the collapsed view.
@epriestley Maybe one to consider: you must have a default workboard column for a project; the default workboard column cannot be hidden; milestone workboard columns strictly sort after project workboard columns. The combination of these three means that I have a project which is strictly split into four milestones, but its overall workboard view always includes an empty column before each milestone column. Is it worth filing a task for this?
Apr 7 2016
Mar 1 2016
Sep 17 2015
@dancunningham @readevalprint Also (and as a reference for anyone else
landing on this page), the actual upstream is at
https://github.com/wikimedia/phabricator-extensions-Sprint - which does
work with current Phabricator. But please do take issues up with them.
Sep 14 2015
@ccope: Yeah, (almost) functionally identical; just a bit slower. The 'almost' is that if you have a branched named T123 in order to automatically link revisions to tasks, your cherry-pick method will succeed (as the branch at time of 'arc diff' is T123), but the rebase method won't (as you'll be on a detached HEAD at the time).
Sep 10 2015
@ccope Try running this over your branch:
git rebase -i --exec 'arc diff -C HEAD HEAD^' origin/master
Aug 13 2015
Yet another set of scripts ...
May 8 2015
Thanks @couture! Sorry mine vanished: it took quite some time to get the CLA signed and I lost all time after that.
Apr 6 2015
Specifically, where in your workflow would you run arc diff on changes which might or might not have been sent for review already without knowing?
Feb 9 2015
Feb 5 2015
@staticshock I think I'm seeing the same thing, except not quite. I have a linear patch history, which I submitted to http://phabricator.freedesktop.org (open access) as D1 through D17 (not in any upstream repositories; only in my local tree and Differential). Each patch was created individually with arc diff, per rationale in T7076.
Feb 3 2015
Looking at my Differential dashboard, I suspect this results from the combination of Blocking Others (ordered D13..D17), and Action Required (ordered D17..D13).
Jan 29 2015
Jan 28 2015
@chad Ha, no. It's a pretty terrible hack to manually construct the tags directly from within buildPropertyView; pulling the revision object and then building up each of colour/icon/etc with a bunch of manual switch statements. Lots of copy-and-paste. If using PhabricatorStatusUI on the revisions is the way to go, I'll see how that works tomorrow and if there's anything I need to do with the revision class itself to implement that?