docs: S5~S7 충돌 재측정(세 base 병기) + 「충돌 수에 base 병기」 §5 상시 규칙 채택 [rustjava-upstream-sync-remeasure-s5-s7-and-lock-restore-basis] - #19
Merged
Conversation
…abel the base" S5~S7 새 충돌을 PR #18(--merge) 착지 뒤 기준으로 재측정하고 세 base 를 병기했다. 같은 컷 ba5797b 가 base 에 따라 19(계획 03438b0) · 112(복원 전 3a59776) · 4(복원 후 8c1238b)로 갈린다 ⇒ 「충돌 수에 base 병기」를 §5 상시 규칙으로 채택. - 새 충돌(복원 후): S5 +3 · S6 +0 · S7 +1. S5 는 「충돌 0 물량」이 아니다. - 그 +3 은 upstream 이 아니라 우리가 앞 회차에 남긴 로컬 분기가 만든다 (string.rs = 설계 판단 · test_timer.rs = S4 가 넣은 2000ms 여백 · Cargo.lock). - 「예측은 하한」이 S7 에서 처음 깨졌다(+3 예측 ↔ ⓐ+2 · ⓒ+1) — Cargo.lock 이중 계상 · class_format_error.rs 경로 오기 · throwable.rs 는 S3 가 수렴시켜 충돌이 사라졌다. - 부수 발견: 「7회차」는 헤드에 닿지 않는다. ba5797b..upstream/main 12커밋 · 누적 11 · java_runtime→rustjava-runtime · test_data→test-data 개명이 우리 픽스처에 꽂힌다. 사료 보존: 7회차 표는 취소선 + 정정 표지, 2026-08-27 블록은 무접촉. 코드(.rs) 변경 0 · 문서 전용.
added 3 commits
September 4, 2026 00:41
측정 22셀은 전건 정확했다(검수자 독립 재측정). 고친 것은 «그 수를 설명하는 문장» 5건이고, 표·결론은 건드리지 않았다. 1. [major] class_format_error.rs — 「3296139..ba5797b 에서 upstream 변경 0」이 거짓이고 0 인 쪽이 반대였다. 실측 diff --numstat 3296139ba5797b = 4/3(+4/−3) · diff --numstat 3296139 origin/main = 0줄(블롭 0dbd369 동일). ⇒ 충돌하지 않는 이유는 「upstream 이 안 건드렸다」가 아니라 「우리 쪽이 merge-base 와 바이트 동일하다」다. §5 는 S5·S7·S8 티켓이 계획 근거로 읽는 문서라, 전자로 읽으면 «영구 무충돌»이지만 참인 술어로는 «우리가 손대는 순간 충돌»한다. 2. [minor] 우리 쪽 numstat 방향 반전 — string.rs +8/−28 · test_timer.rs +8/−1 (초판은 역순 diff origin/main 3296139 출력). 같은 표의 upstream 열은 방향이 옳았다 ⇒ 한 표 안에서 방향이 섞였다. §5 상시 규칙에 diff 방향 토큰을 추가했다. 3. [minor] 「148(실제 3)」이 두 base 를 섞었다 — 148 은 base 3a59776 의 오파싱이고 그 base 의 참값은 45 다(ⓒ 8c1238b 는 15/참값 3 · ⓐ 03438b0 은 58/참값 17). 4. [minor] S8 인계 경로 오기 — test-data/src/UnsupportedCharset.java (.java 만 src/ 아래). 5. [minor] 구간 커밋 수 표기의 왼쪽 끝점 생략 — 전부 증분임을 명시(누적은 17·18 로 다른 수). 사료 보존: 초판 수치는 전부 «[2026-09-04 정정]» 블록 안에만 남겼다(덮어쓰기 0). 코드(.rs) 변경 0 · 문서 5파일.
…ure-s5-s7-and-lock-restore-basis] PR #20 이 먼저 착지해 REPORT.md·STATE.md 머리에서 위치 충돌이 났다(코드 파일 충돌 0). - REPORT.md: 서로 «다른» 회차의 절 둘 ⇒ 합집합 · 시간순(09-04 → 09-03). 삭제 0줄. - STATE.md: «같은» 항목(s5-s7)의 상세판 vs 요약판이라 상세판을 남기고 요약판 고유 토큰 «PR #19» 를 흡수. 항목 id 집합 소실 0(양방향). main 의 완료 항목은 그대로 보존. 해소면 밖 변경 0 — docs/upstream-sync-approach.md 와 2026-09-03 워크로그 쌍은 승인 형상과 바이트 동일.
…measure-s5-s7-and-lock-restore-basis] STATE.md 진행중 → 완료(게이트③ PR #19 · --merge · 위치 충돌 2건 합집합 해소) + worklog .json 에 게이트③ 집행 1줄. 코드 변경 0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
무엇을
PR #18 이
--merge로 착지해merge-base origin/main upstream/main이3296139c로 전진한 «뒤» 기준으로S5~S7 「새 충돌」을 다시 쟀고, ★세 base 를 병기했다. 코드(
.rs) 변경 0 · 문서 전용.03438b03a597768c1238b(현main)3296139(S4)c4665b0(S5)95ebc5c(S6)ba5797b(S7)⇒ ★같은 컷이 base 에 따라 19 · 112 · 4 로 갈린다(28배). 「4건」과 「112건」은 둘 다 참이고 base 없이는 검증 불가다.
판정 — 「base 병기」를 §5 상시 규칙으로 둔다
형식
<수>(base <sha> · merge-base <sha>)· 병기 없는 충돌 수는 문서·회신·티켓 어디에도 쓰지 않는다.★**「각 회차가 정확히 쓰면 된다」로는 막히지 않는다** — 직전 반려의 실제 형태가 그것이다:
S2 회신(복원 후 5)과 S4 회신(복원 전 20)은 각자는 정확했는데 둘을 «한 표»로 모으는 순간 기준이 섞여
「우상향 계열」이라는 없는 사실이 만들어졌다. ⇒ 깨지는 지점이 «작성»이 아니라 «집계»다.
방법 검증 · 통제
git merge-tree --write-tree --name-only <base> <cut>의 2번째 줄~첫 빈 줄 앞만 센다(그 뒤
Auto-merging블록까지 세면c4665b0가 3 대신 148 로 읽힌다 — 초기 시도가 실제로 그랬다).03438b0)로 돌리면0·1·2·2·7·16·17·17·17·19가 그대로 재현된다.git commit-tree 4788ef2f -p 3a59776)도45·61·112 로 동일 ⇒ PR upstream 동기 계보 복원 — 근인 = 게이트③ --squash (behind 33 → 18, 트리 변경 0) [rustjava-upstream-sync-squash-defeats-convergence] #18 의 문서 4파일 diff는 이 수에 영향 0.
주요 결론
Cargo.lock(재생성) ·string.rs(★설계 판단) ·test_timer.rs(S4 가 넣은 500→2000ms 여백). ★전부 upstream 이 아니라 «우리가 앞 회차에 남긴 로컬 분기»가 만든다.+3↔ ⓐ +2 · ⓒ +1). 원인 3건 전부 실측:Cargo.lock이중 계상 ·class_format_error.rs경로 오기 + upstream 변경 0 ·throwable.rs는 우리 쪽이3296139와 바이트 동일(★S3 의 설계 판단이 뒤 회차의 충돌을 «지웠다»).ba5797b..upstream/main12커밋 · ⓒ 누적 11(+7) ·java_runtime/→rustjava-runtime/·test_data/→test-data/개명 스윕이라 새 7건이 우리 픽스처(
charset.rs·UnsupportedCharset3 ·TimeApi2 ·test_string.rs)에 꽂힌다. 개명 충돌은 픽스처를 조용히 지울 수 있다.사료 보존
검증
python3 scripts/check-worklog-json.py→ checked 5 files, 0 problems ·git diff --name-only origin/main -- '*.rs'→ 0 ⇒ cargo 축은 트리 입력 불변으로 담보.경계
머지 0 · force-push 0 · 리베이스 0 ·
main직접 push 0 · base =main(★스택 PR 아님) ·★upstream(
dlunch/RustJava) 발신 0(전gh호출-R Jun025/RustJava· push 대상origin단독) ·★S5~S7 을 실제로 수행하지 않았다(
merge-tree= 읽기 전용 측정) ·wie-ktf-hardening무접촉.