The proper way to push the fix is arc land...

It always surprised me that updating a git commit and pushing an update, doesn't update the description in phab (which is part 1 of your issue), but I'm pretty sure the second part will lead to the simple "use arc land for landing" reply from the phab devs...

From what I can tell part 2 of the issue is caused by part 1. I have dug into the Arcanist codebase and have noticed a switch --verbatim which can be passed to arc diff which should achieve the effect you desire. Note that you shouldn't pass --verbatim when creating a review for the first time, as otherwise it won't amend the commit message to include the appropriate Differential Revision: https://... line.

Quoting the codebase:

// With '--verbatim', pass the (possibly modified) local fields. This
// allows the user to edit some fields (like "title" and "summary")
// locally without '--edit' and have changes automatically synchronized.
// Without '--verbatim', we do not update the revision to reflect local
// commit message changes.
if ($this->getArgument('verbatim')) {
  $use_fields = $message->getFields();
} else {
  $use_fields = array();
}

If you're comfortable editing JSON, you can also pass --edit to arc diff which will give you substantially more control over what it sends to Phabricator.

Thanks for this pointer - I'm going to try this.

Did that with https://phabricator.kde.org/D9831 and review title has been updated. Updating remaining commit messages not tested yet.

Okay. Given that upstream has in the past rejected other default behaviour change requests - and the current behaviour appears to very much be deliberate, i'm not sure if we should ask them about this.

If you could confirm updating the remaining commit messages works, I think we should document this on our wikis and close this?

In T7711#124542, @bcooksley wrote:

Okay. Given that upstream has in the past rejected other default behaviour change requests

Phabricator does not have site wide property settings to allow sites having different default behavior ?

If you could confirm updating the remaining commit messages works,

I will this on the next review update

Arcanist is responsible for submitting the changes meaning the control is entirely client side and the server has no input.
Best we could do is patch Arcanist and provide a patched version for people to use with the changes we need made, or alternatively use the other Arcanist client written by a third party which i've seen mentioned elsewhere.

In T7711#124543, @habacker wrote:

If you could confirm updating the remaining commit messages works,

I will this on the next review update

I verified that this is working with an update for D10310

In T7711#124544, @bcooksley wrote:

Arcanist is responsible for submitting the changes meaning the control is entirely client side and the server has no input.

The option to document this flag somewhere in the KDE wiki will probably let many new user stumple about this issue, because the related note may be read over.

A better option would be to support arcanist flags in git repo .arcconfig with the drawback thart this requires patching every repo and patching arcanist.

If we need to patch arcanist/phabricator anyway the technical best option I see would be: Arcanist already communicates with the server on submitting patches and it might be possible to fetch server default properties, which may be "use --verbatim by default" for the KDE installation in a future version of arcanist/phabricator. This has the advantage that no user interaction would be required , but the drawback of patching arcanist and phabricator. May be there is already a related phabricator api function for this purpose, which simply needs to be used by arcanist.

Just my 2 cent.