훑는 중인 목록을 GitWorkspace 에 두고 파일 비교 화면에서 이전/다음으로 딛는다. 화면에 보이는 순서를 따르고, 찾은 줄 목록도 같은 방식으로 훑는다. 먼저 묻고 자리를 옮긴다. Ctrl+PageUp/PageDown.
14 KiB
4차 — 로컬 머지툴 사용성 (2026-09-10 ~)
지시서: 작업지시/4차.md
D-1. doc/history/ 를 만들고 진행상황을 나눴다 — 완료 (2026-09-10)
왜 - 진행상황.md 가 721줄이었고 한 파일에 다섯 가지가 섞여 있었다.
주차 목표 · 차수별 상태 표 · 항목별 상세 · 미룬 것 · 완료 기록.
"3차 D-3 에서 무슨 판단을 했더라" 를 찾으려면 스크롤로 뒤져야 했다.
이렇게 나눴다.
doc/
진행상황.md 73줄. 지금 대기·진행 중인 것만
작업지시/
3차.md · 4차.md · 머지툴보강.md · 사용성보강.md
history/
changelog.md 한 줄 요약 + 날짜별 문서 목록
2026-09-08-2주차.md 90줄
2026-09-09-3차.md 565줄
2026-09-10-4차.md 이 파일
옮기기만 하고 내용은 고치지 않았다. 지시서가 그렇게 시켰다 - 다시 쓰면 그때 무슨 판단을 했는지가 흐려진다. 옮긴 자리에 날짜와 제목만 얹었다.
지시서를 doc/작업지시/ 로 옮긴 것은 git mv 로 했다. 새로 쓰고 지우면 이력이 끊긴다.
git log --follow 로 옛 이력을 그대로 따라갈 수 있다.
링크는 열다섯 개가 전부 살아 있다. 옮기면서 다섯 군데를 고쳤다.
doc/작업지시-3차.md → 작업지시/3차.md, 지시서 안의 doc/진행상황.md → ../진행상황.md,
작업지시-머지툴보강.md → 머지툴보강.md. 문서 전체를 훑어 남은 옛 경로가 없는 것을 확인했다.
곁들여 하나 - 미룬 것 목록에 최근 파일 목록 이 남아 있었다. 4차 B-1 로 올라온 항목이라
두 자리에 다르게 적혀 있었다. 미룬 것 쪽에서 뺐다.
판정 기준 확인
| 기준 | 결과 |
|---|---|
| 진행상황.md 200줄 아래 | 721 → 73줄 |
| 대기·진행 중인 것이 한 화면에 | 4차 열세 항목이 한 화면에 들어온다 |
| 끝난 차수 상세를 링크 한 번으로 | changelog 한 줄 → 날짜별 파일 |
| 링크가 깨지지 않음 | 15개 전부 정상 (스크립트로 확인) |
D-2. 앞으로의 기록 규칙을 정했다 — 완료 (2026-09-10)
왜 - D-1 로 자리를 나눠 놓기만 하면 다시 한 파일로 쌓인다. 어디에 적을지를 규칙으로 못박아야 한다.
지시서 작업지시/4차.md 의 공통 규칙을 고쳤다. 항목 하나가 끝나면 세 군데에 남긴다.
- 상세는
doc/history/YYYY-MM-DD-주제.md— 원인 · 판단 · 확인한 결과 진행상황.md은 상태만 — 여기에 상세를 적지 않는다history/changelog.md에 한 줄 — 날짜 · 무엇을 왜 · 커밋
곁들여 둘
- 진행 순서를
A → B → C에서D → A → B → C로 고쳤다. D 를 먼저 하라는 말이 D 묶음 안에만 있어서, 공통 규칙만 읽으면 A 부터 시작하게 되어 있었다. 규칙과 본문이 어긋나 있었다. - 플랫폼 changelog 경로를
UbisamPlatform/doc/history/changelog.md로 풀어 적었다. MergeHub 에도 같은 이름의 파일이 생겨서 그냥doc/history/changelog.md라고 쓰면 어느 쪽인지 알 수 없다. 두 파일은 기준이 다르다 - 플랫폼은 "다른 소비 프로그램에 미치는 영향", MergeHub 는 "무엇을 왜".
판정 기준은 4차 A~C 를 진행하는 동안 이 규칙대로 쌓이는지로 본다. 지금부터 적용한다.
A-1. 저장하지 않은 편집이 말없이 사라지던 것 — 완료 (2026-09-10)
먼저 조사한 것 — 어느 길로 들어오면 사라졌나
HomeViewModel 에서 본문을 다시 읽는 자리를 전부 훑었다. 열한 군데였고 성격이 셋으로 갈렸다.
| 길 | 어떻게 들어오나 | 판정 |
|---|---|---|
OnPlainCompareRequested |
폴더 비교 더블클릭 · 폴더 검색 결과 · 끌어다 놓기 · 탐색기 우클릭 · git mergetool |
막음 |
PickLeftFile / PickRightFile |
기준 파일 · 내 파일 단추 | 막음 |
DropFile |
경로 칸에 파일을 놓기 | 막음 |
OnSelectedFileChanged |
Git 탭 파일 목록에서 다른 파일 고르기 | 막음 (취소하면 목록 선택도 되돌린다) |
OnSelectedNodeChanged |
이력에서 다른 커밋 고르기 | 막음 (취소하면 커밋 선택도 되돌린다) |
OnRemoteBranchChanged |
3-Way 켜고 끄기 | 막음 (취소하면 브랜치도 되돌린다) |
SwitchDemoAsync |
데모 폴더 전환 | 막음 |
RevertAll |
전체 되돌리기 단추 | 막음 (되살릴 수 없어 한 번 묻는다) |
ReloadLinesFrom(keepAsEdited: true) |
비교 규칙 변경 · 무시 규칙 변경 | 안 막음 — 편집을 지키도록 이미 만들어져 있다 |
LoadDefaultPlainFiles |
켤 때 기본 파일 열기 | 안 막음 — 아직 고친 것이 있을 수 없다 |
RefreshCommits → LoadCommitAsync |
커밋·체크아웃 뒤 목록 다시 세우기 | 일부러 안 막음 (아래) |
비교 규칙을 바꾸는 길에 손대지 않은 것이 중요하다. 지시서가 그렇게 못박았고, 실제로 그 길은
keepAsEdited: true 로 편집을 지킨다. 여기까지 확인 창을 붙였으면 규칙 하나 바꿀 때마다 창이 떠서 못 쓴다.
RefreshCommits 는 일부러 두었다. 사용자가 고른 것이 아니라 프로그램이 목록을 다시 세우는 자리다.
그 한가운데 창을 띄우면 무엇에 답하는 창인지 알 수 없고, 취소해도 목록은 이미 새로 세워진 뒤라
되돌릴 자리가 없다. _suspendGuard 로 그 구간만 묻지 않게 했다. 남은 구멍이라는 것은 인정한다 -
커밋·체크아웃을 한 뒤에는 고치던 것이 다시 읽힌다. 다만 그 조작들은 대개 저장한 뒤에 하는 일이다.
어떻게 막았나
ConfirmDiscard(무엇을 하려는지) 하나로 모았다. 고친 것이 없으면 묻지 않는다 -
매번 뜨는 창은 읽지 않고 누르게 되고, 정작 위험할 때도 그냥 눌러 버린다.
세 갈래로 묻는다. 예/아니오로는 "버리고 가기"와 "그만두기"가 구분되지 않는다 -
아니오를 눌렀는데 그대로 열려 버리면 그것이 곧 잃는 것이다.
플랫폼에 MessageUtil.ShowChoice 를 새로 넣었다(플랫폼 ccfed6f).
저장하고 계속 은 커밋하지 않고 파일에만 쓴다(SaveWorkingCopy). Git 모드의 저장은 커밋 메시지가
있어야 하는데 확인 창에서 메시지를 받을 수는 없다. 커밋은 사용자가 따로 할 일이다.
작업 게이트를 타지 않는다 - 확인 창이 UI 스레드에서 답을 기다리는 중이라 게이트를 기다리면 서로 막힌다.
저장이 실패하면 넘어가지 않는다. 여기서 넘어가면 저장한 줄 알고 잃는다.
곁들여 잡은 것 — 고친 것이 없는데도 묻던 문제
만들어 놓고 화면에서 확인하다 걸렸다. 파일을 새로 열어도 HasChanges 가 꺼지지 않아
앞 파일의 상태가 그대로 끌려왔다. LoadPlainFilesAsync 에 그 줄이 빠져 있었다.
지금까지는 저장 단추가 켜진 채 남는 정도라 눈에 안 띄었는데, A-1 이 그 값을 읽으면서 드러났다.
화면에서 확인한 것
| 한 일 | 결과 |
|---|---|
| 고친 뒤 다른 파일 열기 | Other.cpp 에 저장하지 않은 편집이 있습니다 / 다른 파일을 엽니다: WeldController.cpp |
| [취소] | 편집기 내용 그대로, 파일도 그대로, 열린 파일도 그대로 |
| [저장하고 계속] | Other.cpp 에 고친 내용이 쓰이고 WeldController.cpp 가 열렸다 |
| [저장하지 않고 계속] | 파일은 손대지 않은 채 다음 파일이 열렸다 |
| 고친 것 없이 두 번 연속 열기 | 창이 뜨지 않았다 |
검사 514건 통과 · 빌드 경고 0 · 오류 0.
A-2. 내보낸 보고서에 만든 사람이 없던 것 — 완료 (2026-09-10)
왜 - 결과 내보내기 로 뽑은 글에 만든 때 는 있는데 누가 뽑았는지가 없었다.
남에게 보내라고 만든 기능인데 작성자가 없으면 받는 쪽이 되묻게 된다.
이름 판단을 한 함수로 모았다. MergeNote.AuthorOf 를 새로 빼고 MergeNote.Build 도 그것을 쓴다.
설정에 적힌 이름이 없으면 윈도우 계정으로 물러선다. 같은 사람이 같은 화면에서 한 일인데
주석과 보고서에 다른 이름이 남으면 그 자체가 버그다 - 판단이 두 군데로 갈리면 언젠가 어긋난다.
이름이 비어 있으면 줄 자체를 넣지 않는다. 만든 사람: 만 덩그러니 있는 것보다 없는 편이 낫다.
파일 비교 · 폴더 비교 두 보고서에 모두 들어간다. 자리는 만든 때 바로 아래다.
확인한 것
실제로 뽑아 본 파일 머리글이다.
MergeHub 파일 비교 결과
만든 때: 2026-09-10 20:33:17
만든 사람: 김승준
왼쪽 : ...\left\Other.cpp
오른쪽: ...\right\Other.cpp
화면의 머지 주석 미리보기가 // [김승준] 2026-09-10 이었으니 두 이름이 같다.
검사 8건 추가(ReportTest 23 → 31). 전체 522건 통과 · 빌드 경고 0 · 오류 0.
B-1. 최근 비교 목록 — 완료 (2026-09-10)
왜 - 같은 짝을 반복해서 여는데 그때마다 경로를 다시 골라야 했다. 매일 쓰는 사람에게 가장 잦은 마찰이다.
Services/RecentPairs.cs 신설. 화면 없이 검사할 수 있게 기억하는 일만 여기서 한다.
파일 짝과 폴더 짝을 따로 둔다. 한 목록에 섞으면 파일 비교 화면에서 폴더가 나온다. 상한은 15개 - 목록이 길면 고르는 것이 더 느려진다.
저장 형식은 탭으로 나눈 글이다. JSON 을 안 쓴 까닭 - 줄 몇 개가 전부라 라이브러리를 하나 더 매달 값이 없고,
글이면 사람이 열어 보고 손으로 고칠 수도 있다. 윈도우 경로에는 탭이 못 들어가서 나누는 데 문제가 없다.
자리는 D:\UbisamConfig\Settings\MergeHub.Recent.txt 다. 설정 화면에는 안 내놓는다 -
사람이 손으로 고칠 값이 아니고 설정 목록만 어지럽힌다.
켤 때 한 번 읽고 바뀔 때마다 바로 쓴다. 프로그램이 갑자기 꺼져도 목록이 남게 하려는 것이다.
없는 경로를 자동으로 지우지 않는다. 지시서가 그렇게 못박았다 - 네트워크 드라이브나 USB 는 잠깐 안 보일 뿐인데 지워 버리면 다시 찾아 들어가야 한다. 흐리게 보여 주고 열려고 할 때 알린다.
비교가 끝난 짝만 담는다. 읽다 실패했거나 취소한 짝을 남기면 다음에 골랐을 때 또 실패한다.
목록 이름은 양쪽 끝 이름만 쓴다. 전체 경로는 길어서 목록에서 읽히지 않는다.
두 이름이 같으면 하나만 적고(Other.cpp), 다르면 둘 다 적는다(기준.cs ↔ 내작업.cs). 전체 경로는 툴팁에 있다.
여는 길은 다른 데와 같은 RequestPlainCompare 다. 그래서 저장하지 않은 편집도 A-1 에서 함께 걸린다.
화면에서 확인한 것
| 한 일 | 결과 |
|---|---|
| 파일 비교 · 폴더 비교를 한 번씩 | MergeHub.Recent.txt 에 F 줄과 D 줄이 하나씩 |
| 프로그램을 껐다 켜기 | 두 목록이 그대로 남았다 |
| 폴더 최근에서 고르기 | 두 칸이 채워지고 비교가 바로 돌았다 (전체 2개 · 다름 2) |
| 파일 최근에서 고르기 | BASE · Weld.cpp / LOCAL · Weld.cpp 로 열렸다 |
| 짝의 두 파일을 지운 뒤 | 목록에 그대로 남고 흐리게 보였다 |
| 그 죽은 짝을 고르기 | 두 파일 모두 찾을 수 없습니다 토스트, 화면은 그대로 |
검사 33건 추가(RecentTest). 전체 555건 통과 · 빌드 경고 0 · 오류 0.
B-3. 폴더 비교에서 다음 다른 파일로 — 완료 (2026-09-10)
왜 - 파일 하나를 보고 폴더 탭으로 돌아갔다가 다음 파일을 다시 열어야 했다. 다른 파일이 스무 개면 이 왕복을 스무 번 한다.
GitWorkspace 에 훑는 중인 목록(Queue)과 자리(QueueIndex)를 뒀다.
폴더 비교가 채우고 파일 비교가 딛는다 - 두 화면이 서로를 모르는 채로 같은 목록을 봐야 해서
이미 통로 노릇을 하는 이 객체에 뒀다.
원본 결과가 아니라 지금 트리를 훑어 목록을 만든다. 필터로 "코드가 다른 것만" 을 걸어 뒀으면 그 안에서만 움직여야 한다 - 목록에 없는 파일로 넘어가면 왜 거기로 갔는지 알 수 없다.
찾은 줄 목록도 훑을 목록이 된다. 같은 파일이 여러 줄 걸렸으면 한 번만 담는다 - 다음 파일을 눌렀는데 같은 파일이 다시 열리면 멈춘 것처럼 보인다.
최근 목록으로 연 파일은 목록을 비운다. 남아 있던 목록을 그대로 두면 다음 파일이 엉뚱한 데로 간다.
먼저 묻고 그 다음에 자리를 옮긴다. 확인 창에서 취소하면 자리도 그대로여야 하는데, 자리를 먼저 옮기면 취소했을 때 목록 위치만 앞서 나간다. 물은 뒤에는 두 번 묻지 않도록 막는다.
단축키는 Ctrl+PageUp · Ctrl+PageDown 이다. Alt+PageDown(북마크)은 그대로 두었고
검사로 빼앗지 않았음을 확인한다.
화면에서 확인한 것 (파일 네 개 · 하나는 하위 폴더)
| 한 일 | 자리 | 열린 파일 | 이전/다음 |
|---|---|---|---|
| 검색 결과로 열기 | 1 / 4 | A.cpp | 끔 / 켬 |
| 다음 파일 ×3 | 2 → 3 → 4 | B.cpp → C.cpp → D.cpp | 마지막에서 다음이 꺼짐 |
| 이전 파일 ×2 | 3 → 2 | C.cpp → B.cpp | 둘 다 켬 |
| 고친 뒤 다음 파일 → 취소 | 2 / 4 그대로 | B.cpp 그대로 | 편집 내용도 그대로 |
| 다시 눌러 버리고 계속 | 3 / 4 | C.cpp | B.cpp 파일은 손대지 않음 |
검사 5건 추가(ShortcutTest 63 → 68). 전체 560건 통과 · 빌드 경고 0 · 오류 0.