@epriestley what's blocking landing this diff?

It wasn't a major UI issue to start with and yes, you get used to it. I would ignore.

Layout looks very neat but a strange too with that big space gap between the icon on each row and the actual text in this case:

This makes a lot of sense, thanks or the time to explain.

It's possible I'm misreading/misunderstanding this, so maybe the right algorithm is actually to select the "p4" remote ahead of the "origin" remote, i.e. swap steps (2) and (3).

You don’t need to pass any arguments to git p4 sync: the config with the dépôt path to “fetch” latest changelists from is saved inside .git directory. Did you follow the exact instructions I provided?

How about landing this as a prototype?

Now that we are on RDS I can confirm that MySQL also has ONLY_FULL_GROUP_BY enabled by default.

But did you check your spam folder? 😄

That actually using MySQL official Docker image.

Will this affect commits i.e. will newly imported commits have a "create" transaction type?

Is this retroactive to builds in this half state prior to this commit and
deploy?

The above workaround is not reliable since it skips the files entirely vs checking the remaining characters.

Interestingly I worked around the issue by doing the batch edit from the Maniphest search UI which is passing the selected tasks an HTTP body instead of a URL query I guess?

Ah I missed that sentence above, this is why the bot user is disabled:

Mailing list and bot users are also considered "closed" because you usually want to hit normal users instead of them.

Another instance of the bug her:

@epriestley If you just add copy in the selection dialog, it will help a lot IMO:

Got it thanks. And would a build be triggered by plan changes flag through the web form? Or only with another arc diff call?

I understand why this may fall under T2543 but this other task appears to be of much bigger scope and take a very long time to be done, while this seems like a minor enhancement. Plan changes is just an attribute of the revision like summary, reviewers, etc... which you can use as conditions in herald, so why not just add it to herald.

I don't know about that.

Arcanist understands this is a new topic branch which no associated revision yet,

How?

If you or your users sometimes use git push to mean "save changes", "make a backup", "share", etc., you can configure "Autoclose" in Diffusion. For example, you can configure only the "master" branch to Autoclose. If you configure Phabricator like this, it will never close revisions when changes are pushed to other branches.

Expected flow:

• have a topic branch and call arc diff
• create a new topic off the first one then call arc diff again
• Arcanist understands this is a new topic branch which no associated revision yet, so it does arc diff --create <first_topic_branch>

I understand the "why" but not the "why of the why" if that makes sense? What this means is that revisions might be closed in what appears to be unpredictable to users if they happen to push their topic branches to the repo AND have merge commits on them (that's the issue no?).

Interestingly, using arc diff --create to force create a new revision generates one with a patch that still contains the diff of the original topic branch. The solution is to force arc diff to use the tip of the original topic branch as the base whenever calling arc diff while on this secondary topic branch.

Clicking on "Explain Why" shows:

We didn't find a "Differential Revision" field in the commit message. This commit and the active diff of D127 had the same commit hash (70bfb4dd58c56a37296b00632113bd01d9facb83) so we linked this commit to D127.

Oh, it looks like pushing the topic branch when it was at the merge commit resulted in Diffusion auto-closing the Differential revision? This would explain the arc diff behavior reported above, but then the question becomes, why did it auto-close?

I like that, sounds like a very good compromise.

For the record, you can work around the problem as such:

{
  "linters": {
    "filename": {
      "type": "filename",
      "exclude": ["(\\+)", "(\\@)"]
    }
}

please no I am so young and have so much to live for

A possible workflow change might be to use "Edit Parent Tasks" instead of "Merge", to collect separate bugs under a single parent task but not actually close them.

Why is it important to see all the duplicates at a glance?

I just tried again (reloaded tab first) and didn't see the issue... Which is puzzling because I had reloaded the page twice and saw the issue twice before filing this bug.

Yes, your email explains the real behavior under the hood. I filed this task from the perspective of what it looks to the user, not from the engineering implementation perspective. Feel free to change title / description of course.

Still failing as of today (rarely though):

Building in workspace /Users/admin/Jenkins/Home/workspace/Hyper-tvOS-AdHoc
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git # timeout=10
Fetching upstream changes from ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
 > git --version # timeout=10
using GIT_SSH to set credentials Phabricator
 > git -c core.askpass=true fetch --tags --progress ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:763)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1012)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043)
	at hudson.scm.SCM.checkout(SCM.java:485)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1738)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

This has been solved AFAIK since I haven't seen this issue in a while.

I don't know if this is related but since an hour or so, whenever I push I get an error even though the push appear to work (the commits show up in Diffusion):

$ git push
# Push received by "web.phacility.net", forwarding to cluster host.
# Waiting up to 120 second(s) for a cluster write lock...
# Acquired write lock immediately.
# Waiting up to 120 second(s) for a cluster read lock on "repo002.phacility.net"...
# Acquired read lock immediately.
# Device "repo002.phacility.net" is already a cluster leader and does not need to be synchronized.
# Ready to receive on cluster host "repo002.phacility.net".
Counting objects: 56, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (50/50), done.
Writing objects: 100% (56/56), 9.30 MiB | 1.84 MiB/s, done.
Total 56 (delta 32), reused 1 (delta 0)
# Released cluster write lock.
AphrontQueryException: #1364: Field 'messageCount' doesn't have a default value
To ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
   015051e..67b218b  master -> master
error: failed to push some refs to 'ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git'

@epriestley Did you see the AphrontQueryException: #1364: Field 'messageCount' doesn't have a default value problem too?

Hummm I don't know if it was a transient error or I just happened to magically fix it by force pushing to the repo, but git pulls now work again on my Mac and in CI.

Pushing appears to work (as in the commits appear in Diffusion) but errors are printed:

$ git push
# Push received by "web.phacility.net", forwarding to cluster host.
# Waiting up to 120 second(s) for a cluster write lock...
# Acquired write lock immediately.
# Waiting up to 120 second(s) for a cluster read lock on "repo002.phacility.net"...
# Acquired read lock immediately.
# Device "repo002.phacility.net" is already a cluster leader and does not need to be synchronized.
# Ready to receive on cluster host "repo002.phacility.net".
Counting objects: 11, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1.90 KiB | 0 bytes/s, done.
Total 11 (delta 10), reused 0 (delta 0)
# Released cluster write lock.
PHP Fatal error:  Uncaught exception 'FilesystemException' with message 'Requested path '/core/log/hyper' is not writable.' in /core/lib/libphutil/src/filesystem/Filesystem.php:1107
Stack trace:
#0 /core/lib/libphutil/src/filesystem/Filesystem.php(650): Filesystem::assertWritable('/core/log/hyper')
#1 /core/lib/libphutil/src/filesystem/PhutilDeferredLog.php(183): Filesystem::createDirectory('/core//log/hype...', 493, true)
#2 /core/lib/libphutil/src/filesystem/PhutilDeferredLog.php(155): PhutilDeferredLog->write()
#3 [internal function]: PhutilDeferredLog->__destruct()
#4 {main}
  thrown in /core/lib/libphutil/src/filesystem/Filesystem.php on line 1107
To ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
   d77b984..6eb6700  master -> master
error: failed to push some refs to 'ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git'

This is still happening (incidentally just observed because of the build failure due to T11469).

Just observed a failure, see updated description.

Why do you mean by "this instance"?

Until this is implemented, can someone tell me how to unsubscribe from Harbor Master build failure emails (see T11282)?

I was away for dinner and indeed, it was imported when I got back and everything seems good.!

Is there a doc somewhere on how to configure this for Slack though? Can it post only Diffusion updates or does it have to post everything? If the latter, that's going to be way to noisy and won't work I'm afraid.

Ah, I didn't know you had to edit it at https://admin.phacility.com/. I was looking at the instance config app.

I don't think I can change this setting: "Configuration Locked". Can you guys do it for us?

Got it, thanks for taking the time to explain. When you say "metadata" for the commits, do you mean the commits are also in Diffusion (even if invisible)? If so, wouldn't this behavior affect Herald / Harbor Master?

The expected behavior is that when we discover a new commit, we search for any open revision which has an active diff with a commit that has the same commit hash or tree hash as one of the discovered commits. In this case, it appears that this revision did.

Feel free to look at this information and anything else in the Hyper instance you need to.