@JJPMaster Well, consensus to request implementing this change. enwiki has no jurisdiction to compel any change to MediaWiki, and it's a bit irresponsible that the RfC implied it could. (That's on the nominator, not on you as closer, although I'd suggest a word other than "adopt" in the close for maximum clarity.) But as @Novem_Linguae said in the discussion, this should definitely be taken as a data point in favor of this change, and a pretty strong one at that.

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

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

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

Would it be desirable to also have the merge show up in the target page's history? Would that perhaps be sufficient?

In T118132#10775256, @daniel wrote:

Would it be desirable to also have the merge show up in the target page's history? Would that perhaps be sufficient?

That idea was nowhere near as well-received in the enwiki RFC about this topic (but I personally supported it ... and I know enwiki isn't the same as all the wikis using this software). Also, reading the RFC reminded me that there's already a Phabricator ticket about the null edit idea, T341760.

In T118132#10775299, @Graham87 wrote:

In T118132#10775256, @daniel wrote:

Would it be desirable to also have the merge show up in the target page's history? Would that perhaps be sufficient?

That idea was nowhere near as well-received in the enwiki RFC about this topic (but I personally supported it ... and I know enwiki isn't the same as all the wikis using this software). Also, reading the RFC reminded me that there's already a Phabricator ticket about the null edit idea, T341760.

Yea, we'd probably want both.

Nit pick on the side, just because I recently updated the relevant documentation on mediawiki.org: "null edits" are not the same as "null revisions" - null edits are basically purges. I prefer the term "dummy revision" to avoid confusion.

(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, but from a software perspective we might nevertheless want to implement that, might it be an idea to put the histmerge-dummy-revision behaviour behind a config variable that could then be disabled for enwiki?

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, but from a software perspective we might nevertheless want to implement that, might it be an idea to put the histmerge-dummy-revision behaviour behind a config variable that could then be disabled for enwiki?

I for one wouldn't support making this configurable; it's analogous to page moves, which produce a null edit whether you want one or not (partially depending on whether a redirect is suppressed, naturally).

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

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.

In T118132#10775988, @Graham87 wrote:

I for one wouldn't support making this configurable; it's analogous to page moves, which produce a null edit whether you want one or not (partially depending on whether a redirect is suppressed, naturally).

I'd expect to see a dummy revision on the target page, not on the source page.

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 specialise in) and I happened to be an importer (another specialty of mine) ... 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 page because 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.

I'd expect to see a dummy revision on the target page, not on the source page.

Agreed.

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.

I am not inclined to have a feature flag. Feature flags are not free. They add complexity to code, to automated tests, and to debugging.

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.

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.

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#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.

I was thinking about the doubled-up log entries myself, but always thought that was preferable to having no direct evidence of the history merge on the target page at all. The idea of making the mergehistory special page leave evidence of its actions in the same way that page moves do is interesting and I'd support it. Page moves create a null edit on the target side and, if asked to do so (which is true in most cases), a redirect edit on the source side. The mergehistory special page can already create a redirect edit on the source side if needed (i.e. if the history merge results in no revisions being left at the source page), which isn't often.

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.

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

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

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. The double-logging issue didn't even occur to me until my friend who made the patch (on his own initiative) uploaded it, by which time I didn't think it was worth mentioning (because it wasn't really our problem, from my point of view). 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.

Sure, I for one would have no issue with that.

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.

True - one would be findable when looking for actiona affecting the source page, the other would be shown when looking for actions on the destination page. It makes sense to me to be able to find them both way.

Change #1139219 merged by jenkins-bot:

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

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

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). 👍

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

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

I'll merk it for demoing. Let's leave it open until then.

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.