웹 문서가 8차 D-1(E-1 · F-1 전)에서, "지금까지 만든 것" 은 6차에서 멈춰 있었다.
- 개요: 22벌 1,122건 · 커밋 104 · 8차 끝 · 9차 진행 · 다섯 길
- 매뉴얼: 병합 커밋 본문 해결 내역(예시 포함) · 해결 기록이 남는 곳 · 마지막 저장 뒤 기준 HEAD
· 모든 브랜치에서도 고른 커밋 유지 · 넣은 주석 줄 무시 색 · 알아 둘 한계 넷
- 남은 일: 8차 D-1 · F-1 · E-1, 9차에서 고친 것, 9차에 남은 것, 정해서 두지 않는 것
- 지금까지 만든 것: 7~9차 기록 · 하네스 막대 · 기능 목록
확인: 화면 문구 앱 소스 grep 대조, 옛 숫자 0건, 태그 짝 맞음, 아티팩트 버전 9.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5차에 "폴더 비교 뒤 트리를 세우는 데 1초 남짓" 으로 적어 둔 것을 앱 안 임시 측정
(커밋하지 않고 잰 뒤 되돌림)으로 단계별로 쟀다. 4,500개 시험 묶음에서
- 트리 만들기 5~17ms, 첫 화면까지 0.13초 (필터 전체 4,608 노드 0.24초)
- 비교(백그라운드) 데운 뒤 0.68~0.80초 - 기다림의 대부분
- 5차의 1,086ms 는 자동 조작 대기(누른 뒤 0.6초)와 화면 훑기가 섞인 값
줄일 자리가 없어 코드는 바꾸지 않았다. 그날 첫 비교 9.2초(디스크 첫 읽기로 보임)는 적어 둠.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
네 칸에서 Take 하면 넣는 주석 줄이 "추가"(파랑)였다가 다시 정렬하면 "무시"(회색)가 됐고,
LOCAL(Mine) 칸에 내 파일에 없는 주석 글이 번호 없이 보였다. 사용자 결정 "처음부터 무시 색".
- InsertNoteAbove: IsIgnored = Rules.IsFiltered(주석), 네 칸이면 SetThreeWay(null...) 로 Mine 빈 자리
- 규칙 "머지 주석 무시" 를 끄면 지금처럼 추가
- 하네스 NoteTest +5 (69건), 22벌 1,122건 통과, 빌드 경고 0 오류 0
확인: Weld/Unit1.cs Take Theirs 직후 무시 1 · 추가 0, [Aa] 로 두 번 다시 정렬해도 같음,
Undo · Redo 가 주석 줄을 걷고 다시 넣음, 저장 내용(주석 1줄 · 3788줄) 그대로.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
cherry-pick 마지막 [Save] 뒤 두 칸의 기준이 고른 커밋 · 다른 브랜치 커밋 · HEAD 중
하나로 그때그때 달랐는데 요약은 늘 "내 쪽 대비" 라고 했다(8차 E-1 N1 · N1-덧).
새로고침이 이력 목록을 갈아 끼우며 선택을 놓치면 목록 맨 위로 채웠고,
[모든 브랜치] 에서 맨 위는 HEAD 가 아니었다.
- CommitSelection: 작업 중 충돌이 막 0 이 되면 HEAD, 아니면 해시로 되찾고 없으면 HEAD
- GitWorkspace.ReadState: 목록을 갈아 끼우기 전에 고른 해시를 적어 둔다
- ResolvedSummary(baseIsHead): 기준이 HEAD 일 때만 작업 글
- 하네스 MergeSaveTest +18 (201건), 22벌 1,112건 통과, 빌드 경고 0 오류 0
확인: cherry-pick([모든 브랜치]) · revert 마지막 Save 뒤 기준 HEAD, 제목 "가져오기 전 내 쪽",
요약 "내 쪽 대비 … 6줄" = git diff 대조. 사람이 고른 커밋은 새로고침 세 번에도 그대로.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
8차 전부 끝. E-1 에서 새로 걸린 N1 과 전에 남긴 작은 것을 9차로 넘긴다(코드 변경 없음).
- A-1 cherry-pick 마지막 저장 뒤 "내 쪽 대비" 인데 기준은 이력에서 고른 커밋 (먼저 정함)
- A-2 한 번은 다른 브랜치 커밋이 기준 - 새로고침 뒤 선택 복원 (원인부터)
- B-1 MERGED 주석 줄 "무시" 색 (먼저 정함) · B-2 폴더 트리 1초 (재고 정함)
- C-1 웹 문서 8차 끝 · F-1 · D-1 cherry-pick · revert 를 마지막 파일까지 네 칸으로
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
제품 코드 변경 없음. 병합 · pull · rebase · cherry-pick · revert 를 길마다 새 저장소에서
파일 비교 탭을 미리 열지 않고 MergeHub 만으로 끝까지 갔다.
- 다섯 길 모두 커밋(rebase 끝)까지 · 줄끝 · BOM 바뀐 파일 0 · 충돌 표식 0 · class 이름 검사 0
- 7차 A-1 · A-2 · B-1, 8차 A-1 · B-1 · B-2 다시 안 남 · F-1 병합 · pull 본문 26개
- 새로 걸린 것(9차): cherry-pick 마지막 저장 뒤 요약 "내 쪽 대비" 가 실제 기준(이력에서 고른 커밋)과 다름,
한 번 다른 브랜치 커밋이 기준으로 잡힘(따로 재니 재현 안 됨)
- 8차 전부 끝
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PowerShell 큰따옴표 문자열로 적는 바람에 코드 표시(백틱)가 빠지고,
C-1 줄에는 폼피드 문자(`f)가 들어가 "eature/revert" 로 적혀 있었다.
8차 B-1 ~ F-1 여덟 줄을 원래 글로 갈아 끼웠다. 내용 변경 없음.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
충돌 탭 파일 단위 Accept 는 소스에 주석이 안 남고, 병합 커밋 본문은 비어 있었고,
Git 탭 로그는 끄면 사라져 누가 어느 파일을 어떻게 풀었는지 남는 곳이 없었다(사용자 요청).
- MergeResolutionLog: 기록 파일(첫 줄 MERGE_HEAD) 읽기 · 쓰기, 본문 만들기, 메시지에 붙이기
- GitService: 병합 중일 때만 .git/MERGEHUB_RESOLUTIONS 에 적고, CommitMerge 가 본문을 붙인다.
병합 커밋 · 작업 취소 · 새로고침 때 쓸모없는 기록을 치운다
- 충돌 탭 Accept Mine/Theirs/Both · [Save] · Save & Commit · 파일 남기기/지우기 · 머지 주석 자동이 적는다
- Git 탭 메시지 칸에 본문을 미리 채우고, 풀 때마다 새로 채운다(사람이 고치면 두고 커밋 때 붙임)
- 하네스 MergeSaveTest 183건(21건 추가), 22벌 1,094건 통과
확인: 병합 "충돌 해결 26개 · 김승준"(줄 단위 7 · Theirs 15 · 남기기 1 · 지우기 1 · 주석 자동 2),
pull 26개, Accept Mine 기록 뒤 [작업 취소] 로 기록 파일 없음. 줄끝 · BOM 0/33, 회귀 없음.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
제품 코드 변경 없음. doc/web/index.html 이 6차에서 멈춰 있었다.
- 매뉴얼: 창 크기 조절 · 이름 창 잠금 · 폴더 끌어다 놓기 차례 · 작업별 네 칸 제목과 머리 글 ·
MERGED 줄 번호(결과 파일 번호) · pull · rebase · cherry-pick · revert 가 같은 길 · 빈 cherry-pick 안내
- "알아 둘 한계": 7차 · 8차에서 사라진 네 줄을 빼고, 파일 단위 Accept 의 줄끝 · 스냅 한계를 넣음
- 남은 일: 7차에서 고친 것 · 8차에서 고친 것 두 표 + 8차에 남은 것(E-1)
- 숫자: 하네스 22벌 1,073건 · 로컬 커밋 94 · 문서 기준일 2026-09-16
- 발행된 아티팩트도 같은 내용으로 갱신(버전 7)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MergeHub 코드 변경 없음. 플랫폼 셸 창을 고치고 배포했다(플랫폼 커밋 9baf4b2).
사용자 결정(2026-09-16): 첫 Win+↓ 를 두 번 누르기 복원과 같게 · 덮는 창을 창 가운데로 · 1px 테두리는 그대로.
- 첫 Win+↓ 2400×1350@(266,266)(화면 밖 16px) → 2048×1222@(256,153) = 작업 영역 80% · 가운데
- 이름 창 어긋남: 최대화 창 세로 36px → 0 (보통 크기 창은 그대로 0)
- 스냅은 최소 크기(1280×720 DIP) 때문에 화면 반쪽이 될 수 없다 - 고치지 않고 적어 둠
- 화면 잠금은 재지 않았다(잠그면 사람이 직접 풀어야 해 확인이 멈춘다)
- PlacementTest 37건 통과 · 배포본으로 다시 재서 같은 값
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
제품 코드 변경 없음. 시험 저장소 생성기에서 '상대 쪽 작업' 커밋만 작성자를 박지훈으로 두고
MergeHub 와 git 이 같은 일을 하게 해 견줬다.
- MergeHub cherry-pick: 작성자 박지훈 <jihoon@localhost> · 커밋한 사람 시험 <test@localhost>
- git cherry-pick: 같음
- MergeHub revert: 작성자 · 커밋한 사람 모두 시험
- git revert: 같음
- 이력 목록에도 '상대 쪽 작업 dddd515 · 박지훈' 으로 보인다
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
제품 코드 변경 없음. 시험 저장소 생성기(scratchpad C1Repo)에 feature/revert 갈래를 더해
revert 충돌 16개를 만들고 MergeHub 만으로 [Revert] 부터 커밋까지 갔다.
- 머리 "revert 진행 중" · 끝내기 단추 [커밋] · 네 칸 REMOTE "되돌리는 커밋 c579a81 내 쪽 작업"
- 로그 "101행 Theirs(커밋 c579a81) 반영" · 진행 줄 "충돌 정리 끝 - [커밋] 으로 revert 를 끝냅니다"
- 커밋 acefbcd 'Revert "내 쪽 작업"' 부모 하나 · 워킹트리 Clean · REVERT_HEAD 없음
- 바뀐 파일 36개 · 줄끝 · BOM 바뀐 파일 0 · 충돌 표식 0 · class 이름 검사 0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
네 칸 MERGED 칸 번호가 정렬할 때 정해진 채 굳어 있었다. 고른 줄 · 머지 주석으로 결과가 늘어도
다시 매기지 않아 끝 번호가 3363 인데 상태바는 총 3369줄이었다.
- 사용자 결정(2026-09-16): 결과 파일 번호로 맞춘다 - 상태바 · [이동] 칸 · 코드 검사와 같은 기준
- MergedNumbering.Assign - 결과에 들어가는 줄만 1부터 센다
- 줄을 만들 때와 요약을 그릴 때마다 다시 매긴다(고르기 · 편집 · 되돌리기 · 주석 끼우기 뒤)
- LOCAL (Mine) 칸은 내 파일 번호 그대로
- 하네스 MergeSaveTest 162건(번호 7건), 18벌 928건 통과
확인: MERGED 끝 번호 3363 → 3369, 상태바 총 3369줄 · [이동] 3369 · 저장된 파일 3369줄과 같다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
이미 들어 있는 커밋을 cherry-pick 하면 [커밋] 이 켜졌고, 누르면 로그에
"[cherry-pick 커밋] 실패: No changes; nothing to commit." 만 남았다. 진행 줄도 그대로였다.
- GitService.HasStagedChanges() 를 두고 적용 로그 · 커밋 앞 막음에 쓴다
- GitWorkspace.PendingHasChanges 를 상태로 들고, 진행 줄이 그 값을 본다
- CanFinishOperation 은 cherry-pick · revert 에서 커밋할 것이 있어야 켜진다
- 병합 커밋은 트리가 같아도 정상이라 걸지 않는다
- 하네스 MergeSaveTest 155건(진행 줄 7건), 18벌 921건 통과
확인: HEAD 커밋을 다시 cherry-pick → [커밋] 꺼짐 · "가져올 변경이 없습니다 - [작업 취소] 로 끝냅니다" ·
[작업 취소] 로 빠져나옴. 충돌 24건짜리 보통 cherry-pick 은 그대로 커밋까지(원래 메시지).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rebase · cherry-pick 에서 마지막 충돌을 [Save] 하면 파일 비교 탭이 "남은 차이 6줄" 로 떨어져
충돌 탭("충돌 정리 끝 - [계속] 으로 rebase 를 이어 갑니다")과 다른 말을 했다.
- OperationLabels.ResolvedSummary / BaseHeader 로 옮기고 작업별 글을 붙였다
- MergeSavePlan 의 병합 전용 함수 둘을 걷어냈다
- 화면은 IsMergeInProgress 대신 IsOperationInProgress · OperationState.Kind 를 본다
- 하네스 MergeSaveTest 148건(작업별 16건), 18벌 914건 통과
확인: rebase "충돌 정리 끝 · [계속] 으로 rebase 를 이어 갑니다 · 올릴 자리 대비 올린 변경 6줄" · 제목 "올릴 자리",
cherry-pick "… [커밋] 으로 cherry-pick 을 끝냅니다", 병합은 예전 글 그대로.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
파일 비교 탭을 처음 여는 것이 [3분할로 열기] 면 고른 파일 대신 첫 충돌 파일이 보였고,
그 화면을 [Save] 하면 고른 파일에 그 내용이 써졌다(Unit47 이 Unit15 내용으로 스테이징).
- 읽기: 읽는 사이 파일 · 커밋이 바뀌면 버리고, 화면이 지금 고른 파일과 다르면 한 번 더 읽는다
- 쓰기: 저장 · Save & Commit · 파일 지우기/남기기가 화면에 실린 파일과 다르면 아무것도 쓰지 않는다
- 하네스 MergeSaveTest 15건 추가(140건), 18벌 906건 통과
확인: 병합 · pull · rebase · cherry-pick 네 길 모두 고른 파일이 열리고 저장이 그 파일에만 감.
병합은 파일 비교 탭을 미리 열지 않고 끝까지 - 커밋 3ba6314, 줄끝 · BOM 0/33, class 이름 검사 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7차 전부 끝. D-1 에서 새로 걸린 넷과 7차에서 남긴 것을 8차로 넘긴다(코드 변경 없음).
- A-1 고른 충돌 파일 대신 다른 파일이 보이고 저장하면 고른 파일에 써짐 (가장 먼저)
- B-1 rebase · cherry-pick 마지막 저장 뒤 "남은 차이" · B-2 빈 cherry-pick [커밋] · B-3 MERGED 번호(먼저 정함)
- C-1 revert 끝까지 · C-2 원래 작성자 · C-3 창 크기 조절에서 안 본 것
- D-1 웹 문서 갱신 · E-1 다섯 길을 파일 비교 탭을 미리 열지 않고 다시
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
코드 변경 없음. 새 시험 저장소에서 MergeHub 만으로 네 길 모두 커밋(rebase 끝)까지 갔다.
줄끝 · BOM 바뀐 파일 0, A-2 · B-1 다시 안 남, MERGED 줄 번호 안 잘림.
새로 걸린 것(고치지 않음 → 8차):
- N1 파일 비교 탭을 처음 여는 것이 [3분할로 열기] 면 첫 충돌 파일이 보이고,
그 화면을 [Save] 하면 고른 파일에 그 내용이 써진다(Unit47 ← Unit15)
- N2 rebase · cherry-pick 마지막 저장 뒤 "남은 차이"(A-1 은 병합만)
- N3 MERGED 칸 번호가 결과 파일 번호가 아님
- N4 바뀌는 것 없는 cherry-pick 에서 [커밋] 이 켜져 실패
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
셸 창이 최대화 전용이었다. 끌어 크기 조절(최소 1280x720) · 두 번 누르기 최대화/복원 · 화면 이동이 크기를 지킴 ·
크기와 모니터 기억. 최대화는 작업 표시줄까지 덮고(사용자 결정), 크기를 바꿀 때 깜빡이지 않게(검은 칠 99.7% -> 3%).
확인 받고 D:\UbisamPlatform\bin 배포, MergeHub 다시 빌드. MergeHub 네 탭은 최소 크기에서 잘리지 않음. MergeHub 코드 변경 없음.
7차 지시서 E-4 판정 기준을 사용자 결정대로 고침.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
화면이 모든 충돌을 "병합" 으로 불렀다 - rebase REMOTE 가 "THEIRS", cherry-pick 에 "병합 진행 중",
다 풀면 cherry-pick 을 끝낼 단추가 없고, 로그에 RebaseContinue() · Commit(), 다른 브랜치 커밋은 고를 수 없었다.
GitOperationState 로 칸 제목(올릴 자리 · 다시 올리는 내 커밋 · 가져오는 커밋) · 머리 글 · 진행 표시 ·
끝내기 단추(병합 커밋 · 계속 · 커밋)를 정한다. cherry-pick · revert 는 원래 메시지 · 작성자로 커밋.
머지 주석 자동 풀기 · 알림도 같은 뒷일. 이력 탭 [모든 브랜치].
rebase · cherry-pick 모두 줄끝 바뀐 파일 0, MergeSaveTest 125건 통과.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 요청. 지금 셸은 최대화 전용(WindowStyle=None · ResizeMode=NoResize · 끌면 다시 최대화).
걸리는 곳(크기 조절 테두리 · 배율 다른 모니터 · 크기 기억 · MergeHub 고정 폭과 네 칸 정렬 · 모든 소비 프로그램)과
판정 기준(최소 1280x720 · 최대화 복원 · 화면 이동 10번 왕복 · 세 크기에서 잘림 없음)을 적었다. 코드 변경 없음.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pull 은 Git.Pull 만 불러 머지 주석만 다른 충돌까지 사람에게 물었고(26 · 0/26), 알림도 커밋 메시지도 없었다.
MergeAsync 의 뒷일을 AfterMerge 로 빼 pull 도 부른다(24 · 2/26 · 같은 알림).
pull 병합 커밋 메시지는 git 과 같은 "Merge remote-tracking branch 'origin/feature/mine' into feature/mine".
bare 원격으로 화면 확인, [Merge] 회귀 없음. MergeSaveTest 93건 통과.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
병합 때 적는 처음 충돌 목록이 병합 커밋 · 작업 취소 · 터미널에서 끝낸 병합 뒤에도 남았다.
MERGE_HEAD 가 없거나 다른 병합의 것이면 병합 커밋 · 작업 취소 직후와 상태를 다시 읽을 때마다 지운다.
병합 중에는 그대로라 "푼 것 M개 (M/전체)" 는 이어진다. 세 경우 화면에서 확인, MergeSaveTest 88건 통과.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Take Theirs 로그가 3-Way 콤보 값을 써서 "10행 (3-Way 안 씀) 반영" 이었고, Take Mine 은 로그가 없었다.
이제 "10행 Theirs(feature/theirs) 반영" · "10행 Mine(feature/mine) 으로 정함".
충돌 네 칸이면 3-Way 콤보 대신 "병합 충돌 · REMOTE = 상대". 브랜치 3-Way 문구는 그대로.
MergeSaveTest 82건 통과.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
화면 아무 데나 폴더 하나를 놓으면 늘 첫 칸에 들어가 두 번째 폴더가 첫 폴더를 덮어썼다.
DropSlotOrder 로 놓는 차례를 두고, 양쪽이 차면 바로 비교한다. 경로 칸 위에 놓은 것도 차례에 친다.
탐색기에서 끌어다 놓아 다섯 경우 확인. PathTest 62건 통과.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
켤 때 이름 창을 Alt+F4 로 닫으면 이름 없이 본 창을 쓸 수 있었고, 창도 끌려 움직였다.
플랫폼 UserNameDialog 에서 저장 전 닫기를 막고 끌기를 뺐다. 확인 받고 D:\UbisamPlatform\bin 배포.
MergeHub 코드 변경 없음(다시 빌드해 새 Core 를 받음).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
병합 중 충돌이 0 이면 두 칸 요약을 "충돌 정리 끝 · 병합 커밋을 할 수 있습니다 · 내 쪽 대비 받은 변경 N줄" 로,
BASE 제목에 "병합 전 내 쪽". 예전에는 "남은 차이 6줄" 이라 덜 푼 것처럼 보였다.
E-1 기록의 하네스 문장을 바로잡음(MergeSaveTest 기대값은 [Save] 로 고침).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LOCAL 칸을 이 파일에만 쓰고 스테이징하는 단추라 Save & Commit 과 짝이 되게 이름만 바꿈.
알림 · 막힘 안내 · 웹 문서도 Save. 하는 일은 그대로(충돌 24 → 23, 커밋 없음 확인).
7차 지시서: 6차 D-1 에서 걸린 세 가지(마지막 저장 뒤 남은 차이 · 로그 3-Way 안 씀 · 기록 파일 남음)와
pull · rebase · cherry-pick 충돌.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
충돌 26(머지 주석 자동 2) · 파일 단위 Accept 15 · 3분할 해결로 저장 7 · 지우기/남기기 2.
5차 C-1 의 23가지 중 사라짐 18, 머지 주석은 B-5 대로 남음.
새로 걸린 3가지(로그 "3-Way 안 씀" · 마지막 저장 뒤 두 칸 · 기록 파일 남음)는 7차로. 코드 변경 없음.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Io/Unit12.cs 를 고치고 콤보에서 Io/Unit20.cs 를 고르면 확인 창이
"Unit20.cs 에 저장하지 않은 편집" 이라고 했다. [취소] 뒤에는 콤보가
Io/Unit20.cs 를, 화면은 Io/Unit12.cs 를 보여 서로 달랐다.
확인하다 더 큰 것을 찾았다. [저장하고 계속] 이 새로 고른 파일에 썼다.
Io/Unit20.cs 를 고치고 Io/Unit12.cs 로 옮기며 누르자 Io/Unit12.cs 안에
class Unit20 이 들어가고 해결된 것으로 스테이징됐다. 병합 결과가
망가지는 버그다.
원인은 하나다. 콤보에서 고르면 SelectedFile 이 먼저 새 파일로 바뀐
뒤에 변경 처리가 불리는데, 확인 창의 이름과 저장할 곳을 둘 다
SelectedFile 에서 가져왔다.
- ConfirmDiscard: 이름을 화면에 실린 파일(_lastLoadedFile)에서.
Git 모드는 저장소 안 경로로
- SaveWorkingCopy: 쓸 곳도 실린 파일로. 충돌이면 그 파일의 충돌을 푼다
- 취소 뒤 되돌리기를 콤보의 선택 처리가 끝난 다음 차례에
- 저장소가 이미 열려 있으면 생성자에서 목록을 세운다(B-1 빈틈 -
저장소를 먼저 열고 파일 비교 탭을 나중에 열면 목록이 0개였다)
화면 확인 18건 통과(목록 23개, 이름, 취소, 저장하지 않고 계속,
저장하고 계속 뒤 Unit20 은 풀리고 Unit12 는 그대로). 경고 0, 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
병합하고 파일 비교 탭으로 오면 목록이 병합 전 커밋 파일(304개) 그대로
였고, [새로고침] 을 한 번 더 눌러야 충돌 23개가 나왔다. 충돌 탭 목록을
두 번 눌러도 아무 일이 없었고, 안내 글은 없는 "홈 탭" 을 가리켰다.
원인: 새로고침은 게이트를 쥔 채 화면 목록을 갈아 끼우고, 끝나자마자
Git 탭이 게이트를 다시 잡는다. 파일 비교 화면이 그 틈에 목록을 세우려다
"다른 작업 진행 중" 으로 건너뛰었다.
- OnWorkspaceRefreshed: 게이트가 풀릴 때까지 기다렸다 목록을 세운다
- GitWorkspace.RequestOpenConflict: 충돌 파일을 파일 비교 탭에서 열어
달라는 요청을 남겨 두고 탭을 옮긴다(폴더 비교의 넘겨주기와 같은 방식)
- OpenConflictAsync: 목록에 설 때까지 기다렸다 고른다. 이 요청 때문에
화면이 새로 만들어졌으면 기본 저장소를 새로 열지 않는다
- 충돌 목록: 두 번 누르기(MouseDoubleClick), Enter, [3분할로 열기]
- 안내 글과 병합 알림의 "홈 탭" 을 실제 탭 이름으로
화면 확인 17건 통과(병합 뒤 목록 23개, 두 번 누르기와 단추와 Enter 로
네 칸, 파일 비교 탭을 안 연 새 앱에서도 열림, 병합 취소 뒤 Git 탭
새로고침만으로 목록 304개). 경고 0, 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
양쪽이 같은 이름으로 새로 만든 파일에 Accept Both 를 누르면 묻지 않고
두 blob 을 바이트째 이어 붙였다. 결과 파일 한가운데에 BOM 이 하나 더
들어갔고 같은 class 가 두 번 나와 빌드가 안 됐다.
- BothJoin: 두 벌을 각자 제 인코딩으로 글로 풀어 이어 붙인 뒤 내 쪽
형식(인코딩, BOM, 줄끝)으로 다시 쓴다. 규칙은 A-1 의 TextFile.Encode
- ResolveConflict(Both): 바이트 이어 붙이기 대신 BothJoin
- Git 탭 Accept Both: 먼저 묻는다(무엇이 일어나는지, 줄 단위로 둘 다
넣으려면 3분할에서). 단추 도움말
Both 는 없애지 않았다. 이어 붙이는 게 맞는 파일도 있다.
화면 확인 14건 통과(묻기, 아니오면 그대로, 예면 BOM 1개와 CRLF 한
가지, 보통 충돌도 같음). EncTest 10건 추가. 21벌 785건 통과
(새로 빌드한 실행 파일). 경고 0, 오류 0. A 묶음 끝.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
상대가 지운 파일(UD)이나 내가 지운 파일(DU)을 열면 줄 단위 3분할로
끌고 가서 지운 쪽 칸이 통째로 비었다. 범례는 내 쪽에만 있는 줄 89개를
"Theirs only 89" 라고 거꾸로 말했고, 정할 것인 "남길까 지울까" 는
화면 어디에도 없었다. 파일 단위 해결은 이미 바르게 동작했다.
- DeletionConflict: 어느 쪽이 지웠는지, 남기기와 지우기가 각각 어느
쪽을 고르는 것인지(UD 는 남기기=내 것, DU 는 남기기=상대 것)
- LoadFileAsync: 지운 충돌이면 남은 파일을 BASE 와 두 칸으로 보인다.
칸 제목이 누가 지웠는지 말하고, BASE 제목은 (merge base)
- 범례 위 띠: 누가 지웠고 누가 고쳤는지, [파일 남기기] [파일 지우기]
- 남기기는 고친 것이 있으면 고친 대로 남기고, 지우기는 고친 것이
있으면 한 번 묻는다. 푼 뒤 남은 충돌 첫 파일로 간다
- 해결로 저장과 같은 뒷정리를 ReloadAfterResolveAsync 로 모았다
시험 저장소 생성기에 DU 경우를 넣었다(충돌 23개). 뿌리 폴더를 잡고
있는 셸 때문에 다시 만들기가 멈춰서 안만 비우게 고쳤다.
화면 확인 23건 + BASE 제목 고친 뒤 5건 통과. MergeSaveTest 16건 추가.
21벌 775건 통과(새로 빌드한 실행 파일). 경고 0, 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
병합 중에 충돌 파일을 고르면 BASE 와 내 것 두 칸뿐이었다. 읽기는
충돌 갈래(세 벌)로 했지만 켠 것은 지역 변수 threeWay 뿐이고, 화면
틀을 정하는 IsThreeWay 는 콤보에서 브랜치를 골랐을 때만 참이었다.
상대가 무엇을 바꿨는지 안 보인 채 풀게 됐다.
- IsThreeWay: 콤보로 고른 3-Way 이거나 충돌 파일이라 켠 3분할이면 참.
충돌 쪽은 따로 둔 깃발이라 콤보 값은 건드리지 않는다
- LoadFileAsync: 행을 싣기 전에 틀부터 바꾸고, 읽기 갈래는 콤보로
고른 3-Way 만 본다(앞 파일의 3분할이 다음 파일로 새지 않게)
- GetMergeTheirsName: MERGE_HEAD 를 가리키는 브랜치 이름, 없으면
병합 메시지의 이름, 그것도 없으면 짧은 해시
- MergeNames: 병합 메시지에서 이름 꺼내기(저장소 없이 검사)
- REMOTE 제목에 상대 브랜치 이름
화면 확인 18건 통과(충돌 파일 네 칸, 제목 REMOTE · feature/theirs,
콤보 없이 해결로 저장, 병합이 끝나면 두 칸, 콤보 3-Way 는 예전과 같음).
MergeSaveTest 14건 추가. 21벌 759건 통과(새로 빌드한 실행 파일).
경고 0, 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3분할로 푼 파일을 저장하면 줄끝이 전부 LF 가 됐다. 3,363줄 CRLF
파일에서 충돌 6개를 풀었는데 git 에는 파일 전체가 바뀐 것으로 나왔다.
원인은 둘이었다.
- ResolveConflictWithContent 가 인코딩만 맞추고 줄끝을 안 봤다.
편집기 글은 줄마다 \n 이라 늘 LF 로 써졌다.
- 원본으로 워킹트리 파일을 읽었다. 충돌 중에는 git 이 LF 로 충돌
표시를 넣어 두어 원본이 아니다.
- TextFile.Encode: 저장 바이트 규칙을 한 곳으로. "원본 유지" 는
넘겨받은 원본 바이트를 따르고, 줄끝은 가장 많은 것, BOM 은 한 번
- TextFile.Write: 디스크 파일을 원본으로 Encode 를 쓴다
- ResolveConflictWithContent: 원본을 ours blob 으로(없으면 theirs,
base). 고른 저장 형식을 받는다
- HomeViewModel 세 자리가 저장 형식을 넘긴다
Io/Unit12.cs +399 줄 -> +2 -1, CRLF 유지
Motion/Unit0.cs +3367 -3363 -> +8 -4
한글설명.cs CP949 와 CRLF 유지
LineEnding.cs 상대가 LF 로 바꿔도 내 쪽 CRLF
줄바꿈 LF 를 고르면 LF
검사 모음이 빌드 실패를 삼키고 옛 실행 파일을 돌리던 것을 찾았다.
LangTest(5차 B-1 의 CarryOver 변경), ReportTest(파일 누락),
TokenTest(Program.cs 없음, 새로 씀)를 고쳤다. 이제 모두 다시 빌드한
새 실행 파일만 센다. 21벌 745건 통과. 경고 0, 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Save & Commit 이 쓰기, 스테이징, 커밋을 한 덩어리로 돌려서 남은
충돌은 마지막 커밋 단계에서야 막혔다. 화면은 실패라는데 파일은
이미 써지고 스테이징됐고(충돌 22 -> 21), 편집 상태도 안 치워서
다른 파일을 고를 때마다 확인 창이 다시 떴다.
- MergeSavePlan: 지금 커밋해도 되는지 판단만 따로 뺐다
- Save & Commit: 병합 중 다른 충돌이 남으면 아무것도 쓰기 전에 멈춘다
- [해결로 저장]: 병합 중에만 보인다. 이 파일만 쓰고 스테이징한다
- Ctrl+S: 병합 중이면 해결로 저장
- 확인 창의 "저장하고 계속": 병합 중 충돌 파일이면 충돌까지 푼다
화면에서 해 보다 둘이 더 나왔다.
- 게이트에 막혀 건너뛴 목록 불러오기가 빈 결과로 목록을 비웠다.
건너뛰면 그대로 두고, 해결로 저장 뒤에는 게이트가 풀릴 때까지
기다렸다 다시 세운다(WhenIdleAsync). 남은 충돌 첫 파일이 열린다.
- 충돌을 전부 Take Mine 으로 정하면 글이 안 바뀌어 저장할 수 없었다.
3분할에서 충돌을 다 정했으면 고친 글이 없어도 저장할 수 있다.
화면 확인 25건 통과. MergeSaveTest 18건 추가, 21벌 716건 통과.
경고 0, 오류 0. 줄끝(A-1)은 아직 그대로다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자가 정했다. 누가 언제 반영했는지는 소스에 남아야 하므로 머지
주석은 지금처럼 넣는다. 대신 비교하고 병합할 때는 그 줄을 무시한다.
git 은 이 규칙을 모른다. 병합은 주석 줄도 글자로 보고 충돌을 낸다.
그래서 무시는 MergeHub 가 한다.
- 2-Way, 3-Way, 폴더 비교에서 머지 주석을 차이로 세지 않는다
- 줄 끝에 붙은 주석은 조각만 떼고 견준다
- git 이 낸 충돌이 주석 차이뿐이면 묻지 않고 풀고, 두 주석을 다 남긴다
- 무시는 보는 방식일 뿐 파일에서 지우지 않는다. 설정에서 끌 수 있다
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5차 C-1 에서 만든 저장소로 병합을 커밋까지 해 보고 걸린 23가지를
지시서로 묶었다.
A 파일이나 이력을 망가뜨리는 것 (C-1 에서 심각으로 적은 다섯)
A-1 3분할 저장이 CRLF 를 LF 로 바꾼다
A-2 Save & Commit 이 실패라는데 이미 써지고 스테이징됐다
A-3 충돌 파일에 상대 칸이 안 나온다
A-4 상대가 지운 파일을 3분할이 다룰 줄 모른다
A-5 양쪽 새 파일에 Accept Both 가 빌드를 깬다
B 헷갈리거나 막히는 것 8 · C 사소한 것 1
D 고친 뒤 같은 저장소로 병합을 처음부터 다시 해 본다
확인은 C-1 과 같은 생성기로 한다. 고치기 전에 문제가 다시 나는
것부터 보인다. B-5(병합에 머지 주석을 넣을지)는 사용자가 정한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
만든 저장소(파일 303개, 충돌 22개)로 MergeHub 만으로 병합해서
커밋까지 갔다. 지시서대로 고치지 않고 적기만 했다. 제품 코드는
바꾸지 않았다.
맞게 된 것: 병합 결과가 git 과 똑같다(UU 20 AA 1 UD 1 M 7).
3분할에서 충돌 6개를 6 -> 0 으로 줄였고, 파일 단위 Accept 는 고른
쪽과 바이트까지 같다. 부모 둘인 병합 커밋이 생겼다.
걸린 것 23가지. 심각한 다섯:
- 3분할로 푼 파일을 저장하면 CRLF 가 LF 로 바뀐다(커밋에 CR 0개)
- Save & Commit 이 실패라는데 파일은 이미 써지고 스테이징됐다
- 충돌 파일을 고르면 상대(Theirs) 칸이 안 나온다
- 상대가 지운 파일을 3분할이 다룰 줄 모른다
- 양쪽 새 파일에 Accept Both 를 누르면 BOM 이 가운데 하나 더 들어간다
기대값은 사본에서 git 으로 먼저 받아 대조했다. 실제 소스는
열지 않았다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
