Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with subproject "Warp Drive > Thermocoupling"?
Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with milestone "Warp Drive > Milestone 1"?

What it looks like here:
We have the project Grammofy Collections which represents one of our products.
It has a milestone Full Catalog Access
It also has a subproject Grammofy Collections: Frontend/Web

This should now be resolved in HEAD of master and stable. Thanks for the report!

I can't reproduce this. Here's an example of a profile working correctly for me locally:

T12708 is the same root bug. This was more engineering than I could handle.

Yeah, these two bugs are probably connected. But the reproductions steps in my setup are surely more common 😄 When I tried to setup the main dashboard for our install, we changed the tabs a lot of times to find the right way to present the important infos for our users. This swallowing of tabs was pretty frustrating...

Duplicate of T12363: Configuration of "Tab Panel" is lost when 1st tab has no panel assigned

BTW, the original patch was generated using git format-patch, not git diff

The original patch which causes this problem is attached. It was generated using git version 2.10.1.windows.1. git am 0001-Move-lld-Parallel-algorithms-to-llvm.patch will successfully apply the patch, but after uploading it to phabricator and then redownloading the raw diff, it no longer applies. The original patch contains text like this:

T11632 is vaguely related.

Oh, no problem -- we likely won't look into this for a while anyway (T12664 is a big mess of related issues that we'll probably try to fix all at once).

Sorry, I've been slacking on getting you this information. Been swamped at
work. I'll try to get it to you this weekend.

See Contributing Feature Requests, but also note that we're likely to restrict this channel soon because no one reads that document (see T12134#212579).

(We probably won't look at this until T12664 moves forward, but when it does it would definitely be helpful to have a specific set of steps we can take to reproduce the issue locally in a clean repository.)

Isn't that a dup of T8611?

This is not a demo or test install. Please don't make a mess! You can launch a demo install on Phacility if you want to poke around and try things out.

This is rather strange. I don't have the original patch used to create the revision anymore, but I tried it again using the same command I always use to generate patches, and when I upload this new patch, I do not see the same issue. In the first (broken) one, some of the files are marked with V, but in the new (working) one, none of the files are marked as V. This is even though git status shows that they are renames:

Which version of git was used? Can you upload the original patch file used to create the diff?
Which version of git is the server using?

Note that a workaround is to do the following:

Excellent! Thanks @avivey.
This ticket could be closed.

@epriestley Whoops! So embarrassed. Thanks :)

You're on the wrong install by mistake.

You're on the wrong install by mistake.

You're on the wrong install by mistake.

I think you've filed this against the wrong install by mistake.

It saves it to a directory called arc in your repository meta-directory. If you're using git, it would be in .git/arc/.

Thanks for your reply.

You can user arc set-config --local to set a configuration value in a file that is in the repository but is not committed.

You can't explicitly subscribe to a revision you're a reviewer for because being a reviewer makes you an automatic subscriber (and, due to a similar bug to the one here, probably can't subscribe even if you've resigned, today), so you'd need to resign, then explicitly subscribe. Also, I'm not sure we handle the other way (explicitly unsubscribe, then later become a reviewer) correctly. These are tractable.

In T12689#223076, @epriestley wrote:

(But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

• There's probably one fairly narrow bug bug here: DifferentialTransactionEditor->getMailTo() likely includes resigned users but should not.
• Beyond that, when you've resigned, we should probably exclude you from getting indirect mail via a project/package? Maybe? (But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

rPbcd87e0e3f3756970d26d5e9c4a60e4be73ef6a6
rARC3c4735795a2963c5ddff6dceaf60122d01ca3dc0
rPHUa900d7b63e954e221efe140f0f33d3d701524aae

Need version information, please.

There were no commits between friday and today, so I'm not following what you're trying to tell us.

Just merging this over to Facts, I don't anticipate allocating any resources to Maniphest reports before Facts ships.

T10469 is vaguely related.

The works here are on behalf of Solus, for the Solus infrastructure, and not that of my employer, and as such have blanket "own time approval" for the umbrella "Solus Project". This much I can do. Signing a CLA of any description for any purpose is what would entangle employers, something I cannot do.

At this time I'm presently unable to sign a CLA (apologies) due to employment situation, however what I can do is make the following diff Public Domain and relinquish any claims to it, should Phacility wish to correct this behaviour in upstream Phabricator.

Sidenote, it does turn out that in any instance, this will require some kind of empty commit for HEAD to exist, i.e. Repo constructed - but this change at least allows the empty commit to work.

Sorry about that! Thanks for the report.

Possibly we should just remove this flag because bin/storage status is equivalent and bin/storage adjust prompts by default, buuut...

guess macro has a bug too

Us right now:

Specifically, you will be able to get this information from Facts.

It's correct, we will not be allocating resources to fix this before shipping Facts.

@chad: Errrm, I assume that translates to "wontfix"? Because I don't see how a specific well-defined issue in an existing part of Phabricator is a duplicate of "Build some new tool".

FWIW this behavior has also caused data loss on our team more than once. I'll usually trigger it when I'm going to insert a backtick somewhere in the task description to block off pseudocode and I fat-finger Esc instead.

Yes, here's the testimony of one of our user,

Is this something you actually encountered and lost data?

Sounds good, let us know if you run into issues.

thanks - I'll upgrade!

You should be able to use the "reviewers" attachment to get reviewer information. Here's an example of a query which asks for this attachment, and a response which includes it: