Is this a bug report?

Looks like we use the function to mean "codepoints" in some places in phabricator/.

With no claim that this is the world's most elegant fix, I think this may be a fix:

In the short term, I'll accept a patch to do this if you want to test it?

T9640 and T2383 are somewhat related.

When you upload a file that is stored as chunks, the chunks are also files. For example, file F123 may have chunks F124, F125, F126, etc. These files are not normally visible in the web UI but you can see that the next file you upload will skip some numbers (e.g., be F127).

when i run the command:

Why do you believe that files which are split into chunks don't get encrypted?

phabricator b9f35351e9d486f7b825652ba2de0074b35cd2c5 (Aug 29 2016)
arcanist 10e5194752901959507223c01e0878e6b8312cc5 (Aug 26 2016)
phutil d6818e59c1764ede22cad56f8c5b1b527cb6a577 (Aug 26 2016)

I doubt that upstream is interested in adding yet another configuration option, however, in case anyone runs across this issue, the following patch will make phabricator work with newer elasticsearch versions (2+)

Ahhhhhh, awesome thanks! I'll merge this over.

@epriestley:
So far innodb is working. I can't say if it's worse than myisam really, seems pretty similar. Stemming would help a lot but the main complaint I have is the ranking algorithm seems really bad. It doesn't return the most relevant results first. myisam had the same problem though.

The examples that use the BYSETPOS and WKST rules are omitted, because these rules are not supported by Oracle Application Server Containers for J2EE.

I'm sorry you feel that way. These kinds of requests are frustrating for us too, which is why we try to make it clear upfront in the documentation that this is not an appropriate forum for them.

I'm disappointed by this response.

Since it doesn't seem like the documentation is incorrect anywhere, this doesn't appear to describe a bug in Phabricator which we can accept upstream. See Support Resources and Contributing Bug Reports for details on what we do and do not provide support for.

I think you've already mentioned the right answer for my initial question (though I'm not in a state to try it out just yet): arc close-revision. But that's not obvious as an alternative to closing out a diff.

Sorry I though I was clear on how you could reproduce the bug. I will try again

(off hand this may be a duplicate of T8307)

• "Try arc patch" is vague, I don't know where you're running it
  • Version information is required on reports, I don't know what version your running
  • Observed behavior / Expected behavior - I don't know what the error message was, or what happened, nor what you expected to happen. We expect to get a copy of the error if one was present, etc.

Sorry, these steps are vague and incomplete. We don't take bug reports like this and our documentation at Contributing Bug Reports is very clear on what information is required.

@epriestley Yup, thanks, will do. I only meant to see if one was necessary, but I was not clear with that ask. :)

Sorry I though I was clear on how you could reproduce the bug. I will try again

Please file a new task following Contributing Feature Requests if you'd like us to consider your feature request. We do not track resolved tickets.

I'm late to this party, so please forgive me for reanimating an old discussion.

Please see Contributing Feature Requests and Describing Root Problems for guidance on filing a valid feature request. You need to follow all the instructions in those documents before we can accept your request upstream.

Additionally, coming to phabricator, my expectation is that arcanist would handle the front-end (i.e. phabricator), but not strong-arming my local development environment.

That document says:

I was attempting to follow what I understand as the (abbreviated) standard process for a review:

What led you to arc land, specifically?

Also possible is stuff like "the diff has a custom policy which you destroyed", etc.

If an object exists but is failing to load, it's usually because a required related object does not exist (in most cases, "required" means "required in order to evaluate policy checks").

Thanks for responding, Evan.

This isn't a bug -- I think we've just set you up with the wrong expectations somehow. There's probably some sort of documentation we can improve to make it more clear what arc land does, and maybe I can figure out how where we led you astray by asking some questions:

Sorry if I'm not being clear. This is currently not a valid bug report. Please completely and clearly follow the steps in Contributing Bug Reports. The point of this documentation is to reduce the amount of time the upstream spends on bugs. Having clear communication upfront means we don't have to spend 3x the time trying to get the details afterwards.

Applying a patch on the wrong repository.

A solution to what?

I didn't suggest that. A solution can be to not apply that patch and inform the user about that.

Vaguely, it sounds likely you're expecting arcanist to be able to apply multiple patches to multiple repositories, which I don't think is a feature.

Bug reports require clear, easy to reproduce, set of steps anyone can follow. Please read Contributing Bug Reports for how to file a complete bug report.

I've take a look at T7944#194982 and from my understanding you are waiting for some use case to select the best approach.
In my case it's a really simple one and corresponds to display a widget of timeline events, so it's a "kind" of Absolute events.
As I work in french, an iso8601 date representation would be appreciable in order to convert to french date representation.

I believe I've seen these exceptions for the past year or so on our setup as well, though I hadn't actually confirmed the diffs do exist. I did confirm that nobody ever manually deleted diffs though.

Thanks!

Yeah, ON DUPLICATE KEY UPDATE is sensitive to order. Setup:

I think this is:

Presuming setting Public view policy on repo resolves the issue. Let us know if not!

Just throwing in my support for this. I'd love to move away from paid services (aka Jira + Tempo) and use Phabricator.

In T8238#196204, @epriestley wrote:

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

That is, my expectation is that git pull does not "bring everything back".

In T8238#196204, @epriestley wrote:

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

That is, my expectation is that git pull does not "bring everything back".