I think of the "merge-target" and "merge" logs as the same log entry displayed in two different ways, not two different log entries.

Fair enough :) duplicate move-log bug split to T395168: Duplicate log-events sometimes created for page moves.

There's a real software change that would be done if there were infinite resources to do things: only show "merge-target" logs when viewing the logs for a specific page, and not the logs for a specific user (or all logs). That should be tracked on Phabricator somewhere, even though I don't plan to code it and don't expect anyone else to.

True, but (from what I can see) I don't think there is a histmerge bug here — the two log events seem to be expected behaviour as a result of T118132. I guess I was thinking that this ticket would be reframed to be about the move-logs bug only, but no objections to splitting out the move bug to another task :)

The move bug is probably completely unrelated to the histmerge bug and should be split to a different task.

In T395112#10852645, @Count_Count wrote:

Looks like there are no more instances of fully duplicate entries though, more general quarry query: https://quarry.wmcloud.org/query/93916

The move log entries are not exactly duplicate, they differ in the associated_rev_id field of the log_params column.

Looks like there are no more instances of fully duplicate entries though, more general quarry query: https://quarry.wmcloud.org/query/93916

Change #1149646 had a related patch set uploaded (by Codeofdusk; author: Codeofdusk):

[mediawiki/core@master] MergeLogFormatter: Fix `redirect` parameter on wrong link in merge logs

https://gerrit.wikimedia.org/r/1149646

This has resulted in merge log entries at the destination showing "redirect=no" on the wrong link (T395075). For example, https://en.wikipedia.org/w/index.php?title=Special:Log&logid=169948608 should have "redirect=no" on the link to Draft:Percilla Bejano rather than the link to Percilla Bejano.

Shall we mark this as resolved, or does the MW-Interfaces-Team want to track this on their kanban board?

Nice. I have a user script that puts a "log" link on every page, and opens a little panel with all the log entries for that page. Once this patch rides the train, I suspect I can click this, and reliably see if the page has ever been history merged (since the date of the patch anyway). 👍

Change #1139219 merged by jenkins-bot:

[mediawiki/core@master] MergeHistory: Add a log entry at the merge destination

https://gerrit.wikimedia.org/r/1139219

Log entry on the source page already exists. Adding one for the target page seems iffy to me, as it creates a situation where Special:Log/merge would have two entries for each merge action.

In T118132#10829776, @daniel wrote:

I suppose that the issue of double-logging has been discussed during the RFC. From a technical perspective, it's not a problem.

Nope, it wasn't. But if you say that from a technical perspective it's unproblematic, then I have no issues with it either.

Can we go ahead with adding the log entry for the destination page? I'm happy to hit +2 on the patch.

I for one would have no issue with that.

The patch that implements the second log entry is ready to be merged, and what it does reflects the outcome of the RFC. I think it would be nice to add a dummy revision on the target page at some point, but that's not a blocker.

In T118132#10829329, @SD0001 wrote:

Yes but log entries are typically on the source page, and dummy revision on the target page, as in the case of MovePage.

Log entry on the source page already exists. Adding one for the target page seems iffy to me, as it creates a situation where Special:Log/merge would have two entries for each merge action. I don't think there's a precedent for that.

So, on the target page I think we should only add a dummy revision.

In T118132#10776333, @daniel wrote:

It's unfortunate that these were discussed as alternatives - dummy revisions (nearly?) always reflect log entries, so there ahould have been an option 1a+b, meaning a log ewntry *and* a dummy revision.

Change #1139844 merged by jenkins-bot:

[mediawiki/core@master] page: Emit events from MergeHistory when appropriate

https://gerrit.wikimedia.org/r/1139844

Change #1143971 merged by jenkins-bot:

[mediawiki/core@master] page: Test update propagation from MergeHistory command

https://gerrit.wikimedia.org/r/1143971

Change #1139844 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] page: Emit events from MergeHistory when appropriate

https://gerrit.wikimedia.org/r/1139844

Change #1143971 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] page: Test update propagation from MergeHistory command

https://gerrit.wikimedia.org/r/1143971

And for the record, I still disagree with all of these tasks and think the current amount of logging is sufficient for reasons I explained in the RfC.

As the author of T341760, I support dummy revisions for this. Move and protect have dummy revisions. If I am doing investigation into the history of a page and what titles it's been at, i want its old titles displayed prominently in the history.

In T118132#10776333, @daniel wrote:

It's unfortunate that these were discussed as alternatives - dummy revisions (nearly?) always reflect log entries, so there ahould have been an option 1a+b, meaning a log ewntry *and* a dummy revision.

It was a relatively rushed RFC, started in reaction to me losing my adminship after the first-ever ENWP admin recall (see my user subpage for all the details). Many people wanted to let me continue doing history merges (which is one of the things I specialised in) and I happened to be an importer (another specialty) ... so I was granted history-merging permission via T380753. However, when I was an admin, I very much preferred to use selective undelete to do history-merges rather than the mergehistory special pag ebecause of the logging issues, but now I have no choice. This is all a round-about way of saying: I'm not sure how much weight to give the RFC.

In T118132#10775732, @A_smart_kitten wrote:

(possibly a naïve) idea: if - judging by the RfC closure - enwiki specifically doesn't want histmerges to show up in the target page's history as a dummy revision