smoosh the commits?

I am messing something up with git and arc?

Fix the implementation of using pk-zip compressed figlet font files

Okay I figured out what was happening.

1. We observed the issue with using {} as index operator on our production server
2. I updated the Figlet.php on our production server to fix the indexing issue
3. This resulted in getting the zip_open issue, which this error result was cached (return raiseError() vs. a 500 php error)
4. I applied the index issue change and the zip_open change to our test environment and was able to load the diff that was failing in production
5. Someone had previously installed a bunch of figlet fonts on our production server but it was after the last time we duplicated production to our test server - so the tests I was running in our test environment never hit the zip issue directly.
6. On the production server many of the fonts are PK-zip compressed however have the .flf extension. I had been looking for .zip or .tar.gz files so I had assumed none of the fonts installed were compressed.

I'm not sure why the change D21860 did not work to decompress the tar/gzip figlet file

Sorry for jumping the gun on landing that previous one. To my surprise we didn't even have any custom figlet font files installed previously. I did some more thorough testing with this change to ensure that custom figlet font files still work properly, unless they're compressed. I'm not sure why the change D21860 did not work to decompress the tar/gzip figlet file but if it's not worth supporting I prefer to remove the complexity.

Oh whoops. I didn't realize figlet font file format wasn't compressed

Thank you it’s very appreciated!

Thank you!

A user just ran into this exception with Arcanist (current master changeset) while running arc diff (using Mercurial) with PHP 8.1. I haven't looked too in depth but it seems similar to other PHP 8.1 issues.

[2022-05-17 20:49:47] EXCEPTION: (RuntimeException) substr(): Passing null to parameter #1 ($string) of type string is deprecated at [<arcanist>/src/error/PhutilErrorHandler.php:261]
arcanist(head=master, ref.master=3cc486d5c156)
  #0 PhutilErrorHandler::handleError(integer, string, string, integer)
  #1 substr(NULL, integer, integer) called at [<arcanist>/src/repository/api/ArcanistRepositoryAPI.php:807]
  #2 ArcanistRepositoryAPI::getDisplayHash(NULL) called at [<arcanist>/src/repository/marker/ArcanistRepositoryMarkerQuery.php:67]
  #3 ArcanistRepositoryMarkerQuery::execute() called at [<arcanist>/src/repository/query/ArcanistRepositoryQuery.php:20]
  #4 ArcanistRepositoryQuery::executeOne() called at [<arcanist>/src/repository/api/ArcanistMercurialAPI.php:988]
  #5 ArcanistMercurialAPI::getActiveBookmark() called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:2253]
  #6 ArcanistDiffWorkflow::buildDiffSpecification() called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:380]
  #7 ArcanistDiffWorkflow::run() called at [<arcanist>/scripts/arcanist.php:427]
<<< [1] (+8,567) <exec> 8,567,426 us

👀

I find this very intriguing.

Phabricator would benefit from having access certain services (full-text search, full-codebase search, repository graph storage) that very likely aren't practical to write in PHP

Is the purpose of implementing introspection of libraries to allow for building native components that would get picked up and auto-loaded by arcanist?

Browsing Diffusion (namely, loading a file while the published changeset is head, and trying to Skip past commit):

I couldn't immediately reproduce this; it's also probably a bit of a messy fix.

I'll plan to investigate further if possible. I believe in this case the repository was running in observed mode rather than hosted in case that might be a factor.

Ah! lgtm

Ah thank you!

@epriestley - the fix for this landed in the master branch but it doesn't look like that has carried over yet into the GitHub mirror which is used as the install location for most users, and is the current recommendation on https://secure.phabricator.com/book/phabricator/article/arcanist_quick_start/. Is there a delay before the mirror observes the changes or does something need poked for it to propagate?

... and was formally deprecated in PHP 7.4 and removed in PHP 8.0.

The lint emitted says 7.2 (which appears to be correct), a minor inconsistency in the revision description

Just making a note that I did test git a while back and saw behavior that I wasn't expecting; I haven't had a chance to dig further into this. I'm not super familiar with how to visualize the commit graph in git to confirm this but I believe what happened is a graph that looked like this

A  B
| /
C
|
D  (master)

Marking Plan Changes until I test this out in Git

Remove the $obsolete_map and $rebasedActiveCommit and just use $rebasedCommitMap

The second baby has arrived

Switch to using strncmp()

I played around with this some more and this feels pretty solid for resolving most common symbols. I'll poke around some of the mercurial source a bit later this week and see if I can find an easy way for resolving revset/symbols easily though a custom extension.

Don't bother trying to lookup bookmark/tag names when the symbol is a number as Mercurial disallows this. Also fix the revision number mapping which somehow worked? But still does now...

Fix not being able to lookup commit by symbol 0

Include support for revision number and hash-prefix symbols

The "symbol" here could, in the absolute-most-general case, be a short commit hash (abcd1234) or symbolic commit (tip^^^) -- not just a bookmark or tag name -- so I think this trick (though quite clever) may run into trouble some day.

Oh yea... hmm I think it's possible to include support for commit hashes (or prefixes) as well as revision ID -- I'll try out a change real quick to see if it's simple to include support for those symbols at least. Any relativity modifiers ^^ I think are effectively impossible to handle without resorting to individual hg log commands or an extension

More-correct formatting for the revset

Update the revsets used to work around potentially invalid symbols from preventing all symbols from resolving

Ooh actually it looks like this will work

$ hg log --revset "bookmark('re:^symbol$') or tag('re:^symbol$')"

Doing that doesn't fail if the symbol doesn't exist

Hmm could maybe do something like hg log --rev 'bookmark() or tag() or .' to just get every commit that has a potential symbol and then process those. It would end up getting more results than necessary in every case. The query runs relatively quickly (~230ms) on our ~128k commit repository but it only has ~550 tags which I'm guessing is low -- if we tagged every build we'd have ~15k.

Not yet handling the case where an invalid symbol results in failing to lookup any symbols

I didn't see any obvious way of doing this through revsets but I'll try some more experiments. An extension that adds a template keyword, or just a new command for this, might also be an option

Not yet handling the case where an invalid symbol results in failing to lookup any symbols

Provide implementation of ArcanistMercurialCommitSymbolCommitHardpointQuery to enable hardpoint queries for commit symbols.

So that part is correct, but swapping the commit and branch was incidental, and I overlooked it because we usually get the same result: in common cases, this is moot because ancestors(<branch name>) is equivalent to ancestors(<heads of that branch>), and branch(<commit hash>) is equivalent to branch(<branch of that commit>). The latter is always equivalent; the former is equivalent when commit is the single head of branch, which it almost always is in regular use.

But this behavior (on this install) is unambiguously wrong:

...since b7be5c961297 (the parameter) is an ancestor of 162a9c1e8e44 (the first commit in the result set). I'll send you a diff.

Thanks for checking this out

Err, I updated the error message after running those cases so it no longer says "Failed liberating:" but "Failed to update library:"

Sorry I made a side-stop checking out the error-handling behavior from ArcanistLiberateWorkflow - I made some updates so it can detect the failure to avoid indicating success.

Update error handling of ArcanistLiberateWorkflow to detect failure from running rebuild-map.php in a separate process.

Remove log() entirely, let filesystem errors escape outwardly.

Change approach - remove --verbose, remove --quiet, remove most instances of log() being used, keep the instance when an error is encountered.

I didn't make a task for this as it's a fairly small change and the reproduction/test case is also fairly simple.