I really thought I filed as a Feature request. I will reopen there.

Well this is a feature request not a bug request. There is no problem. This feature would be really useful for users that want to download the whole repo for reasons a user may want to upload the files to his or her server doing git clone will take a few minutes because what if the user doesn't have any software that uses git to download the repo. It may take longer if the user doesn't know how to use the software and how to use for example git clone.

Hi please support downloading zip files or compressed files in differential and diffusion.

More specifically, this request is competing with thousands of other tasks vs. 2 developers. If you can't describe a problem this solves, then we can't give it any priority, and it will sit for many years. It's to your benefit to explain the entire use case to us in a manner which we can understand it's impact on all Phabricator users.

"Gerrit has it" doesn't describe a problem to us.

Well so that users could just like download zip files not needing to have git or any other program to be able to download the files. Gerrit support this and Wikimedia is moving to phabricator soon.

See Contributing Feature Requests. We need and want to understand root problems, and don't consider "feature doesn't exist" or "it's something we'd like" a root problem. Specifically in what scenarios are you distributing zip files in a repository why do they need to be downloadable by non-developers?

True... but I could not find a specified favicon.ico location when I did a CTRL+F for this in the HTML source code of this installation and our installation and assumed that there was some fancy JS code going on or whatsoever which

Of course I would double check it this time, and really try the last diff send in the production environnement where i get the problem, to be sure it don't break the world like last time.

@epriestley, do you see it can be easy enough so I can to submit some patch ?

I've never used EC2 and I'm not entirely sure what's involved with it. There are a few things I'd like to try before doing this, one being a reinstall on the local server. If that doesn't work, I will look into EC2.

(If your time is valuable, we're happy to shoulder the entire burden of building a reproduction case and fish around for environmental problems at our consulting rate; see Consulting.)

Or, let me clarify: if you give us a running VM in EC2 with root credentials, that's useful.

If I could provide a virtual machine image of some sort that shows the issue, would that be useful?

Can you give us root SSH access to a server on the public internet where this issue is reproducible?

Integrating Phabricator into an external (unsupported) tool is considered by us to be custom application development. We only can take upstreamable feature requests that state a core problem when using Phabricator itself. I don't know what these apps are nor why you want to use them. It could be there are already upstream plans to provide similar features.

Sorry to say, but this has nothing to do with custom development. As long as you want to feed elasticsearch with phabricator events, my feature request/suggestion was to do it in a way that is usable by elasticsearch-friendly tools without resorting to hacks and customizations on the elasticsearch side ( which is ok to do at some extent, but right now leaves phabricator in a state requesting to fix index mappings on the elasticsearch side - at least).

our goal is to visualize phabricator events using Kibana and/or Grafana using elasticsearch as a data source.

Hi epriestley,
just added all relevant details. Everything is on the task now.

When submitting a feature request, please describe the root problem you are trying to solve. See Contributing Feature Requests.

Hi epriestley,
I switched this to Feature Request and added Elasticsearch on the projects lists.

Can you provide more details on exactly how this is a bug?

This does not describe a bug with Phabricator. For help filing a bug, see Contributing Bug Reports.

Seems convoluted to recreate the ~/.arcrc each time I change the template. Moreover, when the config is modified directly by arc (arc alias for example), it will modify the generated ~/.arcrc. So I'd have to (remember to) copy these additions back to the template.

In would be convenient, but note you could have a more generic problem here: how to store all your credentials. Solutions like Vault could help in this case.

What was the push operation you tryed to do ? By default phabricator prevents dangerous changes (like history rewrite or other operations in which you have to use --force) but this can be disable in repository preferences..

So - a technical team lead would encounter this.

Sorry to disturb everybody, and I find the reason that, in my hooks of repo, there is also one pre-receive hook script.

One use case is indeed in the Java world (we're a Java shop). But support for this would also be really useful in situations where you're working on a feature (or several different features) orthogonally in different branches, and sometimes have uncommitted files lying around you don't want to commit just yet, and have to perform reviews on other people's code to boot. So - a technical team lead would encounter this.

I don't think any of those actually specify the favicon... what does this return (with the right domain)?

Are there any more details that might be useful?

OK, to me those are 2 very different issues, T5000 is about having a workflow integrated into git and this one is just about allowing users to download the diffs submited to phab in the same exact same form as proposed instead of a stripped down version... I am not sure how you can say they are the same issues, but anyway, looks like there is no way we agree on that at that point (second time you close the issue, in one day...)

I've marked D14699 as fixing this, but it only applies to the EditEngine form, see T9905.

OS: Fedora 22, kernel 4.2.5-201.fc22.x86_64
PHP: 5.6.15
Webserver: Apache 2.4.17
svnserve: 1.8.13
mysql: Ver 15.1 Distrib 10.0.21-MariaDB, for Linux (x86_64) using readline 5.1