We discussed this briefly out-of-band, but the draft part of this is probably only sensible as "soft" prioritization:

• Does that description sound approximately like what you're hitting?
• Are both smarter arc land and arc cascade interesting, or are you only running into pain in one of the cases?
• Do you anticipate cases where git reflog and local notes could fail as sources (lots of pushing/pulling to different working copies, I guess)?
• Anyone know offhand how to git rebase -i master; delete the first few lines; save and exit; non-interactively?

I think the immediate issue here tends to manifest as arc land requiring users to manually rebase before it will work.

@eadler Did you have enough insight/recollection as to whether all our reported cases were due to users editing in the web UI?

Here are the interactions I can come up with which we'll potentially get wrong by implementing this naively:

From a technical point of view I think the ideal solution to this is to make the commit message format unambiguously parseable, but I'm not immediately sure how to do that without making other things worse. It's valuable for messages to be human-readable and human-editable, and I think we'd be worse overall if we tried to escape or encode messages in Git itself (or represent them as XML or whatever).

I'm not sure I have a good answer to that. :/

What's the behavior you'd expect or prefer when a user writes this commit message?

I can't reproduce this. Here's what I did.

My understanding is that the root issue here is that you're adding reviewers via Herald/Owners (per T10939) so the "no reviewers" warning is inaccurate or misleading in many cases because owners will be added automatically after the revision is created.

How often do you anticipate needing this functionality?

We require reproduction steps for bug reports. I would also use an up to date version of Phabricator before filing the bug report (it's required that you update before filing a bug).

Create a custom query inside Phriction, save it, then go to Dashboards and make a Panel with that query.

looks like an awesome feature to me

Configure pygments.dropdown-choices.

Thank you we basically created two projects to group the members into those two projects and i removed myself and only stayed in one and that seemed to kind of work. I see only the files i expected but also some deleted files history that is greyed out. It would be nice to have an easy place to put custom queries to be used for each of the apps but I love Phabricator so keep up the good work thanks.

This is expected. You do not need edit permission to comment on a task or take other actions available in the action dropdown.

In the case of Projects (v3) it looks like you used it to bucket things based on who was assigned, but this doesn't seem like a very feasible / useful thing to do until T5474 is done, because otherwise it's a very manual process.

It feels like the more formal / correct way to do it I guess? Like, I'd expect in future that reporting would occur over milestones in a project, and not columns on a workboard, because the columns don't have any relation between them (as opposed to milestones which explicitly have a "next" and "previous" milestone).

I guess another question is, what are you using Milestones for if they are just a column on the parent?

We used full workboards on our Milestone for Projects (v3). If we linked by default to the parent project, that functionality would be lost. Any sort of auto-redirect to the parent loses all project functionality and power.

As far as I understood it, milestones being projects were an implementation detail, because @epriestley didn't want to have two separate structures for sub-projects and milestones.

You can default a project's page to whatever you want in under Manage Menu. But I don't think that's what you want. I understand what you want, I just would have concerns that it might be unexpected in most cases, especially if you're running the Milestone as a full fledged project with it's own boards.

What's the point of it being a project then?

(I realise that milestones are projects, but I simplified my response to distinguish between the parent project and the milestone that is under that parent project)

No, I'm suggesting that when you click the "Project (Milestone)" tag in the UI, it should take you to the project's workboard.

You're suggesting Milestones should not be projects?

Where is this configurable?

It's configurable.

We should get this punted out of prototype status, don't think there is a lot to cover before that. See T11167 if you find additional items.

This spawned a healthy set of followups, but I believe the core work described here is now resolved and accounted for and all future work is covered in narrower followup tasks.

Appears resolved and accounted for.

I believe this is resolved and accounted for, let us know if anyone runs into issues.

This appears to be resolved and accounted for. There's one followup in T11120 (8bit vs base64 mail encoding) which also might be fixed now. If anyone runs into issues, let us know.

I believe this is now resolved and accounted for. See the remarkup documentation for some details.

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

I believe this is now fixed and all the business stuff is wrapped up on our side. If anyone runs into issues, feel free to file a followup describing what you're hitting.

Sorry, my screenshot was garbage since all the text to the right was INCREDIBLY CONFIDENTIAL SECRETS.

Oh, on task view, I was looking the edit page.

Isn't Badges a Prototype?

Yeah doesn't repro in Chrome.

FWIW, examining every ref like that is a complete no-go for our situation

OK, so I just manually removed the branch from info/refs and packed-refs and I think that maybe that worked?

I think D16136 will "fix" the problem and I can't come up with any problems it creates, although it would be nice to figure out where the mystery ref is coming from.

okay so basically ghosts?

In T9028#180932, @joshuaspence wrote:

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

Ah interesting. From our GitLab host, I see that git branch --all shows a whole bunch of local branches and only a single branch of the form remotes/origin/url_shortener.

I think checking if git ls-remote origin in the working copy lists a refs/remotes/origin/XYZ ref in the authoritative remote is the easiest way to check, although I'm not 100% sure that refs/remotes/ isn't magic with respect to ls-remote.