Can you point us at where in the UI these are used, exactly? Just want to make sure we're fixing the right thing.

@fooishbar - would something like a "collapsed" or "comments-only" view be what you're thinking of? In the example comments you listed there was a 6-month time-span between the two comments. Having ~30 events listed seems natural for a popular task. If it was a few days to a week that would be more frustrating/difficult to read, but I also imagine far less common.

Oh, one problem with that script: when you move all the subprojects or milestones out from under a parent, it doesn't set the parent's hasMilestones or hasSubprojects fields to 0 for you. That'll have to be done by hand in the database.

I'm in the position where I need to re-parent an existing hierarchy of projects, which isn't supported by @epriestley's move_beneath.php above. Rather than attempt to figure out everything involved in doing that (which I think is mostly messing with the various projects' path, pathKey, and depth fields, in case anyone wants to try) I threw this script together to move an existing subproject or milestone to root level, where it can then be moved using move_beneath.php.

@storrgie, since it was a test environment, I disabled it

We can clean this up for phortune a bit better.

This is the expected method.

For reference, the Chromium project has a formal definition of their OWNERS files, including parsing code (in Python).

BTW is the print action the expected method to get an "invoice" for my records? Or can you download a formal invoice from somewhere?

It has the visible effect of removing the page header and footer.

The heuristic only triggers if the repository was previously empty. So it might possibly get a false positive on the very first pull request to a new empty repository, but should be fine after that.

@epriestley Is there a way to disable T9554's heuristics? With patchsets of 30+ patches which get pushed in a single atomic bundle, we don't want to go back to import mode and lose all notifications.

@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.

Note that when you do this, you may generate a large amount of email you don't want, because you're adding commits to a repository which was previously marked as fully imported (it "completed" the import process when it was an empty, hosted repository). You may want to disable publishing in "Publish/Notify". See also T9554.

I can't reproduce this. Here's what I tried. First, I created a new, empty, hosted Git repository:

If you know the ID/monogram of the room (should be in the subject of any email you received, looks like Z123), I think you can also bin/policy unlock Zxxx it, which should make it public. Then you should be able to rejoin it.

@benjumanji, I added you to Community so you should have some new powers to abuse.

Hm, Problem solved:
In my case there has been ServerName FooAddress defined in the default-server.conf while my vhost for Phabricator was configured to ServerName FooAddress.FullAddress.com. It seems as if Phabricator then was jumping between those two addresses?

I'm sorry for bringing this up again - I've got the exact same problem and there's nowhere else to discuss the issue.

@avivey Turning off the autoclose feature, fixed the error. I'm fine with this. Thanks for the pointer!

Right at the top of the home page...

Can someone please help me delete this?

you can likely manually modify the conference_participant table in ${NAMESPACE}_conpherence. The structure is straightforward.
This is likely not a good idea to do on a regular basis.

Great, I'm glad to hear things are working for you. Thanks for your help testing this out!

Interestingly, if I cut and paste the whole command (Over 4200 hashes) on the command line, it works fine (I think my command line limit is at 2MB on Ubuntu 14.4).

Ah, sorry about that!

OK, I was able to reproduce this; The key is to have 1000s of autoclose branches.

Oh, the actual implementation would be --revision (with a short option), I was just using --the-revision-for for clarity (or extra confusion?) in discussing the meaning/behavior of the flag.

My gut feeling is that our users will feel that arc browse --the-revision-for HEAD is too verbose for something that to them is a common and "should be simple" operation. However, if combined with the default behavior as you suggest, such that just arc browse defaults appropriately it would avoid that being a problem while keeping the meaning of the --the-revision-for HEAD option clear.

Wooo! I think this completely covers my old request at T9520: Allow Workboards to show a thumbnail image within each card. :-)

Some earlier discussion in T5781, although I didn't really have a clear way forward at the time and still don't.

does ./repository update work for the smaller repo?
I don't think that's an issue with the length of the command (I'd expect a different exit code - 126, and I think our command execution bypasses this limitation). Exit code 127 might mean that when you invoke it in this way, it can't find git.

haha, no, i don't like it either, but it is at least intentional. I just didn't have any better ideas (and I think we took two passes on it).

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.

'No points' or simply showing nothing is less information

Can confirm that on latest stable my lfs-test repository now succeeds with both jars and jpegs. Huzzah!

@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

I believe less information when the user has chosen to collapse the nav is aligned with expectations.

I think it would be preferable to keep a log of bulk edits that were performed in a global(?) history, and allow them to be reverted easily? I think that would mitigate the issue described in the comment above, and provide value in the event someone unintentionally bulk edits the incorrect set of tasks / objects.

How many branches/tags in the large repository?

@chad If the verbosity is essential, perhaps it should be word-wrapped in the collapsed case, rather than truncated?

The language is that no tasks have points, 'no tasks' might solve a small edge case, but as soon as the first task appears with no points, the longer text is more correct. We tend to lean towards over explaining cases as to limit upstream support time.

@chad OK, fair enough; I guess just close this and I'll build something locally.

My overall concern here is it's a coinflip as to whether that information is useful or not. Mentions nearly always are and while probably not subscriptions, designing a complicated, magical display around thin edge cases doesn't seem like a good use of upstream time. It's unclear that other installs see the same problem (we tend to have tasks that are of high interest for years).

See Contributing Feature Requests for what information we look for in feature requests. This feels more like design feedback (which we don't take as tasks).

From T10891:
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.