Ubisam-MergeTool/doc/history/2026-09-17-9차.md
ksj09406 5710e522bb 9차 A-2: HEAD 를 보고 있었으면 커밋 뒤 새 HEAD 를 따라간다
8차 E-1 에서 한 번 다른 브랜치 커밋이 기준이 된 것은 A-1 과 뿌리가 같았다
(새로고침에서 선택을 놓치면 목록 맨 위로 채움). A-1 대로 해시만 지키자
cherry-pick [커밋] 뒤 선택이 옛 HEAD 에 남아 방금 커밋한 줄이 "남은 차이 6줄" 로 보였다.

- CommitSelection.Choose(previousHeadSha): HEAD 를 보다가 HEAD 가 움직이면 새 HEAD
- GitWorkspace: 지난 새로고침의 HEAD 를 들고 있다
- 하네스 MergeSaveTest +5 (206건), 22벌 1,117건 통과, 빌드 경고 0 오류 0

확인: 8차 E-1 cherry-pick 순서([모든 브랜치] 켬)를 여섯 번 - 시작 · 파일 단위 = 고른 커밋,
마지막 Save 뒤 = HEAD, [커밋] 뒤 = 새 HEAD · 차이 없음. 다른 브랜치 커밋이 잡힌 회차 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-17 11:31:30 +09:00

9.3 KiB
Raw Blame History

9차 진행 기록 (2026-09-17 ~)

지시서: ../작업지시/9차.md

A-1. cherry-pick 마지막 저장 뒤 "내 쪽 대비" 라고 하지만 실제 기준은 이력에서 고른 커밋이다 (2026-09-17, 완료)

사용자 결정(2026-09-17): 작업 중 충돌을 다 풀면 두 칸의 기준을 HEAD 로 옮긴다. ("기준은 고른 커밋 그대로 두고 글을 맞춘다" 는 고르지 않음.)

고치기 전에 다시 났다 (길마다 저장소를 새로 만들어, 파일 비교 탭을 미리 열지 않고)

8차 E-1 순서 그대로 — 이력에서 커밋을 골라 시작 → 한 파일만 남기고 파일 단위 Accept Theirs → 남은 파일을 [3분할로 열기] → 충돌마다 Take Theirs → [Save].

cherry-pick ([모든 브랜치] 켬) revert ([모든 브랜치] 끔)
이력에서 고른 커밋 상대 쪽 작업 내 쪽 작업
마지막 Save 뒤 두 칸 기준(Selected Commit) 뒤이은 수정 — HEAD(내 쪽 작업)도 고른 커밋도 아닌 다른 브랜치 커밋 뒤이은 수정 = HEAD
BASE 제목 ace42e3 · Weld/Unit1.cs (꼬리 없음) … · Motion/Unit0.cs · 되돌리기 전 내 쪽
요약 충돌 정리 끝 · [커밋] 으로 cherry-pick 을 끝냅니다 · 내 쪽 대비 가져온 변경 6줄 … · 내 쪽 대비 되돌린 변경 6줄
  • 8차 E-1 에서 따로 잰 한 번은 기준이 고른 커밋이었다. 이번 cherry-pick 은 목록 맨 위(다른 브랜치 커밋), revert 는 HEAD. 같은 순서인데 기준이 셋 중 하나로 그때그때 달랐다 — N1 과 N1-덧(9차 A-2)은 뿌리가 같다.
  • 파일 비교 탭 왼쪽 이력에서 선택된 줄이 맨 위 뒤이은 수정 이었다(스크린샷 d9-a1-pick-before-1).

원인

  • 새로고침은 이력 목록(Commits)을 비웠다가 다시 채운다. 그때 Git 탭 이력 목록(SelectedItem 바인딩)이 선택을 놓치면 null 을 밀어 넣어 고른 커밋이 빈다. 놓치는지는 그때 화면 상태에 따라 달랐다.
  • 비었으면 SelectedCommit = Commits[0] — 목록 맨 위로 채웠다. [모든 브랜치] 를 끄면 맨 위가 HEAD 라 티가 안 났고, 켜면 맨 위는 가장 최근의 다른 브랜치 커밋이다.
  • 안 비었으면 이력에서 고른 커밋(cherry-pick 할 커밋)이 그대로 기준으로 남았다.
  • 요약(OperationLabels.ResolvedSummary)은 기준이 HEAD 인지 보지 않고 "내 쪽 대비" 를 붙였다. BASE 제목은 HEAD 일 때만 작업 글을 붙여서 둘이 다른 말을 했다.

고친 것

  • Services/CommitSelection.cs(새로) — 새로고침 뒤 고를 자리: 작업 중 충돌이 막 0 이 된 새로고침이면 HEAD, 아니면 새로고침 전에 고른 커밋을 해시로 되찾고, 없으면 맨 위가 아니라 HEAD(HEAD 도 목록에 없을 때만 맨 위). "막 0 이 된" 때만 옮긴다 — 그 상태에서 사람이 다른 커밋을 골라 보면 스테이징 · 새로고침마다 HEAD 로 끌어오지 않는다.
  • GitWorkspace.ReadState — 목록을 갈아 끼우기 전에 고른 커밋의 해시를 적어 두고, 채운 뒤 CommitSelection.Choose 로 새 목록의 같은 커밋 객체를 고른다.
  • OperationLabels.ResolvedSummary(…, baseIsHead) — 기준이 HEAD 가 아니면 작업 글을 쓰지 않는다(보통 요약). HomeViewModel 은 BASE 제목과 같은 조건(SelectedCommit.ShortSha == HeadSha)을 넘긴다.
  • 하네스 MergeSaveTest 18건 추가(201건): 해시로 되찾기 · 순서가 바뀐 목록 · 비었을 때 HEAD · 사라졌을 때 HEAD · 막 0 이 되면 HEAD · 머무는 동안 안 끌어옴 · 기준이 HEAD 가 아니면 보통 요약.

확인한 것 (고친 앱, 같은 순서)

cherry-pick ([모든 브랜치] 켬) revert
마지막 Save 뒤 Selected Commit 내 쪽 작업 = HEAD 뒤이은 수정 = HEAD
BASE 제목 e039373 · Weld/Unit1.cs · 가져오기 전 내 쪽 6dde274 · Motion/Unit0.cs · 되돌리기 전 내 쪽
요약 충돌 정리 끝 · [커밋] 으로 cherry-pick 을 끝냅니다 · 내 쪽 대비 가져온 변경 6줄 … · 내 쪽 대비 되돌린 변경 6줄
git 과 대조 git diff -U0 HEAD -- Weld/Unit1.cs = 바뀐 줄 6 + 머지 주석 줄 6. 주석 줄은 규칙(무시: 머지 주석)대로 안 셈 → 6 이 맞다 같은 구성(+12 −6)

곁 확인(d9-a1-keep.ps1):

경우 결과
충돌을 다 푼 cherry-pick 저장소를 다시 열기 기준 HEAD · 요약 작업 글
그 상태에서 파일 비교 탭 이력으로 바탕 을 고름 → [새로고침] 세 번 세 번 모두 바탕 그대로(HEAD 로 안 끌려감) · 제목 꼬리 없음 · 요약 "차이 없음"("내 쪽 대비" 안 함)
작업 없음 · [모든 브랜치] 켬 맨 위 뒤이은 수정 이 아니라 HEAD 내 쪽 작업 그대로
Git 탭 이력에서 상대 쪽 작업 을 고름 → [새로고침] 세 번 세 번 모두 상대 쪽 작업 그대로
[모든 브랜치] 를 꺼 고른 커밋이 목록에서 빠짐 HEAD 로
  • 하네스 22벌 1,112건 통과(+18) · 빌드 경고 0 · 오류 0.
  • 병합 · pull · rebase 의 요약 · 제목은 기본값(baseIsHead 참)으로 8차 B-1 검사가 그대로 통과한다. 화면으로는 9차 D-1 에서 다시 본다.

알게 된 것 · 남긴 것

  • Git 탭 이력에서 커밋을 고르면 파일 비교 탭의 Selected Commit 은 새로고침 전까지 따라오지 않는다(Git 탭은 _workspace.SelectedCommit 만 바꾸고, 파일 비교 탭은 새로고침 알림으로만 다시 읽는다). 이번에 바꾼 것이 아니라 전부터 그랬다. 고치지 않고 적어 둔다.
  • A-2(한 번은 다른 브랜치 커밋이 기준)는 이번에 원인(목록 맨 위로 채움)이 드러나 함께 고쳐졌다. 지시서대로 A-2 에서 같은 순서를 다섯 번 넘게 되풀이해 확인한다.
  • 자동 조작 쪽: 첫 확인 스크립트는 Git 탭에서 HEAD 를 골라 파일 비교 탭을 봤는데 위의 까닭으로 안 바뀌어, 파일 비교 탭 이력에서 고르게 고쳤다.

A-2. 한 번은 기준이 HEAD 도 가져온 커밋도 아닌 다른 브랜치 커밋이었다 (2026-09-17, 완료)

원인 (A-1 에서 드러남)

  • 8차 E-1 N1-덧의 f310f49(다른 브랜치의 뒤이은 수정)는 목록 맨 위였다. 새로고침이 이력 목록을 갈아 끼울 때 Git 탭 목록이 선택을 놓치면 고른 커밋이 비고, 비면 Commits[0] 으로 채웠다. [모든 브랜치] 를 켜면 맨 위는 가장 최근의 다른 브랜치 커밋이다.
  • 놓치는지는 그때 화면 상태에 따라 달라 "같은 순서로 다시 재니 안 났다". 9차 A-1 의 고치기 전 확인에서 다시 났다(기준 ace42e3 "뒤이은 수정").
  • A-1 에서 해시로 되찾고 없으면 HEAD 로 채우게 고쳤다(CommitSelection).

고치며 새로 걸린 것 → 함께 고침

  • A-1 대로 해시만 지키자 cherry-pick [커밋] 뒤에도 선택이 옛 HEAD(내 쪽 작업)에 남아 파일 비교가 방금 커밋한 줄을 "남은 차이 6줄" 이라고 했다 (되풀이 확인 첫 회차에서 남). 예전에는 선택을 놓치면 맨 위(새 커밋)로 가서 우연히 "차이 없음" 이었다.
  • CommitSelection.Choose(…, previousHeadSha) — HEAD 를 보고 있다가 HEAD 가 움직이면(커밋 · 체크아웃) 새 HEAD 를 따라간다. 다른 커밋을 보고 있었으면 그대로 둔다. GitWorkspace 가 지난 새로고침의 HEAD(_lastHeadSha)를 들고 있다.
  • 하네스 MergeSaveTest 5건 추가(206건): HEAD 를 보다 커밋하면 새 HEAD · 다른 커밋을 보고 있었으면 그대로 · HEAD 가 안 움직이면 그대로 · 처음 열기 · 새 HEAD 가 목록에 없음.

확인한 것 — 8차 E-1 순서를 여섯 번 (d9-a2.ps1)

회차마다 저장소를 새로 만들고, 파일 비교 탭을 미리 열지 않고, [모든 브랜치] 를 켜고 이력에서 상대 쪽 작업 → [Cherry-pick] → Weld/Unit1.cs 만 남기고 파일 단위 Accept Theirs → [3분할로 열기] · Take Theirs · [Save] → 충돌 탭 [커밋]. 새로고침이 일어나는 곳마다 Git 탭 이력의 선택 줄과 파일 비교 탭 Selected Commit 을 적었다.

지점 기대(규칙) 6회 결과
[Cherry-pick] 뒤(충돌 24) 고른 커밋 상대 쪽 작업 6/6
파일 단위 Accept 뒤(충돌 1) 고른 커밋 6/6
마지막 [Save] 뒤(충돌 0) HEAD 내 쪽 작업 · 제목 "가져오기 전 내 쪽" · 요약 "내 쪽 대비 가져온 변경 6줄" 6/6 (Git 탭 · 파일 비교 탭 둘 다)
[커밋] 뒤 새 HEAD(cherry-pick 커밋) · "차이 없음" · Working Tree Clean 6/6 (첫 회차는 고친 뒤 되풀이 스크립트의 1회)
  • 다른 브랜치 커밋(뒤이은 수정)이 기준으로 잡힌 회차 0.
  • 하네스 22벌 1,117건 통과(+5) · 빌드 경고 0 · 오류 0.

남긴 것

  • 자동 조작 쪽: 되풀이 스크립트가 처음에 한 회차만 돌았다. PowerShell 변수 이름은 대소문자를 가리지 않아 안쪽 반복 횟수 $rounds 가 회차 수 $Rounds 를 덮었다. 이름을 바꿔 다시 돌렸다.
  • Git 탭에서 고른 커밋을 파일 비교 탭이 새로고침 전까지 안 따라오는 것(A-1 에 적음)은 그대로다.