Sorry, this fell through the cracks -- feel free to make noise about anything policy-related like this if I don't pick it up in a couple of days.

Maybe rename the edit page "advanced" or something, and let anyone with "can view" see it?

See also T9192.

I think this is a very low-impact change, but not an unreasonable one (the data is already available on the object, I think, and we do already show "Inactive", which is a somewhat similar state). This would make the list view marginally more useful in a tiny number of cases.

Oh, sorry, I'm just moving stuff around on some boards so I can feel accomplished.

I'm ~1 week away from actually having our ducks in a row so we can merge upstream, would expect to land this right about then. Not sure if workboard implies some kind of scheduling?

Do we actually have a reproduction case for this? I'm not sure where I'm supposed to click getLinterName to reproduce this.

for me it seem the imported git repository is a fully functional repo and the original git repo is fully imported only the diffusion's database changeset import partition.

We may have some support for this after T1562, but probably will never have sufficiently granular upstream support to solve this particular problem. I don't anticipate ever disclosing who cloned things in a web-accessible way.

In T9524#139448, @epriestley wrote:

Yeah. If we did the bar UI, I think the length of the bar is just "U + C" (divided by the longest bar shown on the page, I guess? Or like log-base-something of that so the absolute length of the bar always has about the same meaning?) with something like "C / (U + C)" percent of it colored in.

Or it could just say "2% of 23,000 Coverable Lines" but I suspect that would be harder to parse at a glance than a bar if you have a bunch of subdirectories.

https://secure.phabricator.com/diffusion/symbol/getLinterName/?lang=php&repositories=PHID-REPO-08d9fc47cf397db6ce83%2C[object%20Object]&jump=true

[object%20Object] should not be there. See (2).

Quoted Text

no probaly it's the same. is there any chance to fix it? we'd like to migrate all of our development infrastructure to phabricator. without this feature we can't migrate our git repo to diffusion. is there any other even manual way to migrate move ...old git repo under phabricator?

Is this different than T6878?

Oo
Already done in D14290

Yup! Much improved, thanks.

@justinkao can you confirm this has been resolved?

I want to see stuffs like this too - this commit is messy, isn't it?

This workflow is essentially unheard of in Git

In my mind I imagined it similar to GitHub's forking, with the exception that the Pull Request happens a little differently and is seen first in the upstream repository, unless that is specifically what you're referring to here.

In T9562#140172, @epriestley wrote:

I'd be inclined to show N branches, for some small value of N like 3 or 5 or 10, with a link to "Show 1,695 more branches which contain this commit...".

Preferentially choosing autoclose branches to order first in that N might be desirable, although picking the first N that the VCS gives us may be faster or more scalable (e.g., if you had 170,000 instead of 1,700, the cost to select the "good" ones might not be worth paying).

I'd be inclined to show N branches, for some small value of N like 3 or 5 or 10, with a link to "Show 1,695 more branches which contain this commit...".

A nice middle ground would be if I could specify to show some branches by default—for example, just autoclose branches—and to have others hidden unless specifically requested.

I think that change is tentatively within the realm of reason, but I have some concerns.

@epriestley: I'm considering looking at solutions for this, as this is a minor-but-frequent nuisance as a result of our development workflow. I think my approach will be to check during Autoclose that the commit seen is in the same repository associated with the revision before continuing. My gut tells me this is not a change you want upstream - and that if there is a plan for this, the change might be a bit more complex than what I can stomach at the moment. I would like to get an idea of what you have in mind however, that I can keep an eye out while digging around. Below I'm trying to better verbalize our workflow process that results in us seeing these problems.

Particularly, the command server wire protocol is completely different from the HTTP/SSH wire protocol (and pretty reasonable overall, although it's solving a much simpler problem).

We have some CommandServer stuff too, although I don't think it has ever been reachable from the UI. I don't remember if the original use case was improving arc performance or improving import/parser performance.

I have also started looking into other potential projects which may have had to deal with these issues, though I don't believe anything I've found has caught up to bundle2 yet.

• Kallithea - probably not helpful - imports mercurial python library
• Allura/ForgeHg - probably not helpful - imports mercurial python library
• JavaHg - uses command server
• chg - maintains command servers to avoid python spinup time

So we probably need to special case the unbundle command, decode the response, build additional parts from stderr, and then insert them into the response.

I suspect it's worthwhile for us to support bundle2 eventually. As far as I can tell from my investigations in T9450:

Navigate to the equivalent of https://secure.phabricator.com/conduit/method/repository.create/ on your install for full details.

There's a conduit call for it - repository.create - and a little practice will probably let you fill all the details.

Yeah. If we did the bar UI, I think the length of the bar is just "U + C" (divided by the longest bar shown on the page, I guess? Or like log-base-something of that so the absolute length of the bar always has about the same meaning?) with something like "C / (U + C)" percent of it colored in.

No you're correct and I'm getting what you're saying now.

I'm tentatively OK with upstreaming that if we can find a way to present the data that communicates both the coverage percentage and total line size of each directory. In the screenshot above, the current directory might be nearly uncovered if async_diff/ has 95% of the code, or well on the way to coverage if submit_queue/ has most of the code, right?

Anyways, tl;dr; that column is useful to us.

I have a bad habit of quickly reading things and responding without exactly comprehending what's been written, you didn't say what I thought you said about the coverage totals.

I agree with you philosophically, I think that coverage is mainly a heuristic we use to determine whether you're entering an area of the codebase that has been "well cared for". For us, typically, if you pull up a subproject in one of our repositories and there is no coverage, you will probably treat everything in there with extreme distrust. Actual coverage percentages don't matter to us so much.

Short answer is: yes, eventually, but it's not something I plan to prioritize in the near term.

Do you plan on incorporating a coverage column in the UI? I have actually already created a "coverage" application which rolls up coverage information per directory and shows us that info, which is how I surfaced this bug.

I can't reproduce this:

I've experienced this too. When credentials are wrong, it should at least give an option to correct them.

D14243 should fix this. You can cherry-pick it safely if you don't want to upgrade yet, although cherry-picking changes to the Celerity map may be tricky.

I just realized this is specifically targeted towards hosted repositories. Would it be a separate effort for support extensions for externally-hosted repositories? For example, in order for the Phabricator server to keep its local clone of the repository it must have largefiles enabled. This can currently be worked around by turning on the extension for all repositories by modifying /etc/mercurial/..., however there will be no support for arc diff/patch etc.

I would be interested in helping with benchmarks as desired. I have a Mercurial repository with commits dating back to 2004, ~97k commits in total with currently ~7.5k files. Though, I tried running hg blame on a few files which contain unmodified lines since as far back as 2009 and the blame happens near instantaneous.

That fixed it. Thanks!

I think D14239 fixes this, can you update and let me know if you're still seeing issues?

Thanks for the verification!