FlexMeasures / flexmeasures / 36756765420
86%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 188
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 86.206%. Remained the same
36756765420

push

github

web-flow 
Say what does and does not prevent a stacked branch's post-squash conflicts (#2626)

* Say what does and does not prevent a stacked branch's post-squash conflicts

The stacked-branch section explains how to recover after a base is squash-merged,
but not how to spend less time there, and the obvious guess at prevention is wrong.

Merging `origin/main` into the stack before the squash does not help: the squash
commit shares no ancestry with the base's commits, so the stacked branch's merge-base
with `main` stays behind them however recently it merged `main`, and the base's
content still arrives twice. It only removes unrelated changes from the conflict
surface.

What does help, in order of how much: not squash-merging a branch that has something
stacked on it, since a merge commit makes the stacked branch's merge-base the base's
tip; and, failing that, merging the base down the stack before it is merged, which
leaves the stacked branch holding the base's tip exactly. That makes the
reconstruction in steps 1 to 3 unnecessary -- the section now says to skip to step 4
when it applies -- and confines the conflicts to files both branches appended to.

Written from doing it the second way on a four-branch stack: the conflicts came to
one file rather than four, and the duplication still happened, which is what prompted
saying plainly that merging the base down is a mitigation and not a cure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015He1XE7G7HN1svS7Nxgth4
Signed-off-by: F.N. Claessen <claessen@seita.nl>

* Address review: drop the anti-policy advice, define duplication, adopt the one-step resolution

Three changes, all from @Flix6x's review.

The recommendation not to squash-merge a branch with something stacked on it is
gone. This repository has a squash-merge policy for pull requests, so advice to
depart from it per pull request does not belong in its own instructions.

"Duplication" is now define... (continued)

20717 of 24032 relevant lines covered (86.21%)

0.86 hits per line

Jobs
ID Job ID Ran Files Coverage
1 36756765420.1 188
86.21
GitHub Action Run
Source Files on build 36756765420