Idea: keep tested-configuration rows from becoming a shared merge-conflict point #45

New issue

Open

opened 2026-11-12 23:57:21 +00:00 by mooki · 2 comments

mooki commented

2026-11-12 23:57:21 +00:00

The idea

Keep the evidence requirement, but stop independent test results from competing for the same insertion point in docs/tested-configurations.md. The merged Forgejo PR template still asks for a row for each measured run, and the contribution guide still asks contributors to rebase when main moves.

Current scale, checked 2026-11-12 at 23:50 UTC: 1 of 18 open Longshot pull requests touches that file: PR 16 by TrashPanda. That comes from each open PR's changed-file list, not its description. The larger GitHub backlog has not moved here yet, so this is a preventive proposal, not a claim that today's forge already conflicts on every merge. I have not measured conflict-related check time on Forgejo; its ordinary CI migration is still open in PR 13.

Two possible steps:

A local-rebase convenience: add docs/tested-configurations.md merge=union to .gitattributes. Independent rows added at the same place are then both kept by local Git instead of requiring hand resolution.

Measured on this forge, 2026-11-12, Forgejo 17.0.1: with that attribute on the base branch, two throwaway PRs adding a row at the same place were initially mergeable. After the first merged, the second reported mergeable: false and the forge refused it with merge, squash and rebase alike, just as for the control pair without the attribute. A local git rebase with the attribute kept both rows without stopping. The experiment used five throwaway PRs in my own fork; they and their test branches were cleaned up afterwards. The attribute does not remove Forgejo's conflict state or the need to push again; it only makes the contributor's local rebase automatic.
Separate files for new rows: a PR adds a uniquely named small file under, for example, docs/tested/, containing just its table rows. Distinct PRs would no longer edit the same table insertion point. A small script assembles the existing table and those rows for readers, and a game-free check validates the columns. Decide whether assembly is done at release time or presented as a generated view; do not require every contributor to commit the same regenerated table, which would recreate the conflict.

The existing table can stay where it is; only new rows need the new path. I can prepare either step or both, including the guide/template changes so contributors still have one clear place to put evidence. Tools such as towncrier use separate fragments for the same reason.

Anything else

Union has a real cost: if two branches edit the same existing row, it can retain both versions instead of making someone resolve them. It is best suited to append-only entries and still needs review; a format check alone does not settle conflicting evidence.
Separate files remove this shared insertion point, not every possible merge conflict. Their names must be unique, and assembly should catch duplicate entries.
Option identifiers and setting tables have their own collision risks. This proposal does not change them or the in-play controls already merged in PR 7.
Keeping one file and accepting the rebases is also a reasonable answer, especially at today's smaller scale. In that case I would resolve my own affected branches when a reviewer is ready, rather than refresh every PR after every unrelated table merge.

Would you prefer the union attribute as a small local convenience, separate files for new results, or no workflow change yet?

Moved from NotRexed/Hookshot#2924.

Assisted-by: Claude Fable 5.2
Co-Authored-By: Claude Fable 5.2 [email protected]

### The idea Keep the evidence requirement, but stop independent test results from competing for the same insertion point in `docs/tested-configurations.md`. [The merged Forgejo PR template](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/18) still asks for a row for each measured run, and the contribution guide still asks contributors to rebase when main moves. **Current scale, checked 2026-11-12 at 23:50 UTC:** **1 of 18 open Longshot pull requests** touches that file: [PR 16 by TrashPanda](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/16). That comes from each open PR's changed-file list, not its description. The larger GitHub backlog has not moved here yet, so this is a preventive proposal, not a claim that today's forge already conflicts on every merge. I have not measured conflict-related check time on Forgejo; its ordinary CI migration is still [open in PR 13](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/13). Two possible steps: 1. **A local-rebase convenience:** add `docs/tested-configurations.md merge=union` to `.gitattributes`. Independent rows added at the same place are then both kept by local Git instead of requiring hand resolution. **Measured on this forge, 2026-11-12, Forgejo 17.0.1:** with that attribute on the base branch, two throwaway PRs adding a row at the same place were initially mergeable. After the first merged, the second reported `mergeable: false` and the forge refused it with merge, squash and rebase alike, just as for the control pair without the attribute. A local `git rebase` with the attribute kept both rows without stopping. The experiment used five throwaway PRs in my own fork; they and their test branches were cleaned up afterwards. **The attribute does not remove Forgejo's conflict state or the need to push again; it only makes the contributor's local rebase automatic.** 2. **Separate files for new rows:** a PR adds a uniquely named small file under, for example, `docs/tested/`, containing just its table rows. Distinct PRs would no longer edit the same table insertion point. A small script assembles the existing table and those rows for readers, and a game-free check validates the columns. Decide whether assembly is done at release time or presented as a generated view; do not require every contributor to commit the same regenerated table, which would recreate the conflict. The existing table can stay where it is; only new rows need the new path. I can prepare either step or both, including the guide/template changes so contributors still have one clear place to put evidence. Tools such as towncrier use separate fragments for the same reason. ### Anything else - Union has a real cost: if two branches edit the **same existing row**, it can retain both versions instead of making someone resolve them. It is best suited to append-only entries and still needs review; a format check alone does not settle conflicting evidence. - Separate files remove this shared insertion point, not every possible merge conflict. Their names must be unique, and assembly should catch duplicate entries. - Option identifiers and setting tables have their own collision risks. This proposal does not change them or the in-play controls already merged in [PR 7](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/7). - Keeping one file and accepting the rebases is also a reasonable answer, especially at today's smaller scale. In that case I would resolve my own affected branches when a reviewer is ready, rather than refresh every PR after every unrelated table merge. Would you prefer the union attribute as a small local convenience, separate files for new results, or no workflow change yet? --- Moved from NotRexed/Hookshot#2924. Assisted-by: Claude Fable 5.2 Co-Authored-By: Claude Fable 5.2 <[email protected]>

mooki referenced this issue

2026-11-13 00:20:59 +00:00

docs(tested): retain historical Hookshot Linux rolling results #53

mooki commented

2026-11-13 01:49:47 +00:00

Author

Until there is a decision here I handle it on my side: a small script carries a branch onto the new main, keeps both sides' rows and refuses if anything outside the table differs. I can open a pull request for whichever fix is preferred: one small file per run, assembled into the table, or rows grouped under dated headings so that different days do not touch the same lines.

A data point from today for this idea. Main gained one results row at 01:35 UTC (the DLSS model settle fix, #39). At that moment 14 of my 16 open pull requests stopped merging, each with a conflict in `docs/tested-configurations.md` and nowhere else (checked with `git merge-tree` for every head; the two that still merge add no row at the top of the table). Each of the 14 now needs a rebase and, by the rules, a fresh suite run on the new head, for a merge that touches none of their code. The rows all go in at the same place, the top of the table, which is why any two pull requests that add a row collide. Until there is a decision here I handle it on my side: a small script carries a branch onto the new main, keeps both sides' rows and refuses if anything outside the table differs. I can open a pull request for whichever fix is preferred: one small file per run, assembled into the table, or rows grouped under dated headings so that different days do not touch the same lines.

mooki referenced this issue

2026-11-13 02:36:25 +00:00

WIP: fix(docs): give tested runs independent result files #96

mooki commented

2026-11-13 02:36:27 +00:00

Author

I recommend a separate file per run, with the combined table generated for reading but not committed. The prepared change is pull request 96 (work in progress, waiting for your decision on the workflow).

I checked Forgejo 17.0.1's source and replayed its Git commands with Git 2.56.0. Its conflict check runs this in the bare base repository:

git merge-tree --write-tree -z --name-only --no-messages --merge-base=ANCESTOR BASE HEAD

A committed merge=union rule did not resolve the overlapping additions there. Its temporary merge repository also reproduced the conflicts with git merge --no-ff --no-commit tracking, git merge --squash tracking and the rebase paths when the attribute was already shared. A full local checkout did honour union. This matches the live experiment already recorded above; I did not create more test pull requests or change the forge.

The pinned sample now includes the 16 moved pull requests plus the two new ones, #75 and #78. Against main 77f605a25, 13 of the 18 heads conflict in the results table; 14 have any conflict. Moving just their inserted rows into distinct files reduces the table conflicts to 0, leaving the unrelated conflicts in #68 and #75. This is a conversion experiment, not a claim that the existing remote heads become mergeable without being updated. Six branches also need their as above wording expanded before the new row check accepts them.

Option	Evidence and cost
Keep the table	13 results-table conflicts in the pinned sample; no workflow change
Union attribute	Still 13 in the bare conflict check. A local checkout kept both conflicting edits to an existing row, duplicated an overlapping row and retained two incompatible headers, all with exit 0
Dated headings	0 table conflicts against this particular main, because its new row is on the next day. In all 153 pairs of the real row additions applied to the same base, 137 still conflict
Separate files; uncommitted assembled view	0 results-table conflicts in both experiments. More small files; a one-time conversion of open branches; a command is needed for the combined view

The prepared change migrates all 82 existing rows without changing their text or order. It preserves the three duplicate pairs already in the old table rather than deleting evidence. New files contain one self-contained row; checks cover the header, columns, date, duplicate rows and stale generated views. The contributor guide and pull request template name the same destination. Edits to the same existing file still conflict normally.

The remaining maintainer choice is whether this contributor workflow is wanted. There is no required server setting or release automation. A browser-hosted combined view could be added separately, but committing a regenerated table in every measured pull request should be avoided: it recreates the shared insertion point.

I recommend a separate file per run, with the combined table generated for reading but not committed. The prepared change is [pull request 96](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/96) (work in progress, waiting for your decision on the workflow). I checked Forgejo 17.0.1's source and replayed its Git commands with Git 2.56.0. Its [conflict check](https://codeberg.org/forgejo/forgejo/src/tag/v17.0.1/services/pull/patch.go) runs this in the bare base repository: ``` git merge-tree --write-tree -z --name-only --no-messages --merge-base=ANCESTOR BASE HEAD ``` A committed `merge=union` rule did not resolve the overlapping additions there. Its [temporary merge repository](https://codeberg.org/forgejo/forgejo/src/tag/v17.0.1/services/pull/merge_prepare.go) also reproduced the conflicts with `git merge --no-ff --no-commit tracking`, `git merge --squash tracking` and the rebase paths when the attribute was already shared. A full local checkout did honour union. This matches the live experiment already recorded above; I did not create more test pull requests or change the forge. The pinned sample now includes the 16 moved pull requests plus the two new ones, #75 and #78. Against main `77f605a25`, 13 of the 18 heads conflict in the results table; 14 have any conflict. Moving just their inserted rows into distinct files reduces the table conflicts to 0, leaving the unrelated conflicts in #68 and #75. This is a conversion experiment, not a claim that the existing remote heads become mergeable without being updated. Six branches also need their `as above` wording expanded before the new row check accepts them. | Option | Evidence and cost | |---|---| | Keep the table | 13 results-table conflicts in the pinned sample; no workflow change | | Union attribute | Still 13 in the bare conflict check. A local checkout kept both conflicting edits to an existing row, duplicated an overlapping row and retained two incompatible headers, all with exit 0 | | Dated headings | 0 table conflicts against this particular main, because its new row is on the next day. In all 153 pairs of the real row additions applied to the same base, 137 still conflict | | Separate files; uncommitted assembled view | 0 results-table conflicts in both experiments. More small files; a one-time conversion of open branches; a command is needed for the combined view | The prepared change migrates all 82 existing rows without changing their text or order. It preserves the three duplicate pairs already in the old table rather than deleting evidence. New files contain one self-contained row; checks cover the header, columns, date, duplicate rows and stale generated views. The contributor guide and pull request template name the same destination. Edits to the same existing file still conflict normally. The remaining maintainer choice is whether this contributor workflow is wanted. There is no required server setting or release automation. A browser-hosted combined view could be added separately, but committing a regenerated table in every measured pull request should be avoided: it recreates the shared insertion point.