기획안 1차 범위 "커밋 우클릭 -> 이름 변경". 사용자 결정대로 좁은 범위에서만 한다.
HEAD 가 아닌 커밋의 메시지를 바꾸면 그 커밋부터 HEAD 까지가 새 해시로 다시
써진다. 고른 커밋의 메시지만 갈고 뒤 커밋은 트리 · 작성자 · 작성 시각 ·
부모 관계를 그대로 두어(LibGit2Sharp Refs.RewriteHistory) 해시만 바뀐다.
바꾸기 전 자리는 refs/original/날짜-시각/ 에 남긴다.
막는 자리(메뉴는 켜 두고 눌렀을 때 까닭과 푸는 길을 알림으로):
작업 중 · 커밋 안 한 변경 · 지금 브랜치 조상 아님 · 원격에 올라감 ·
다른 로컬 브랜치도 품음 · 구간에 태그 · 사이에 병합 커밋.
파일 비교 탭의 저장 안 한 편집은 우클릭해 줄을 고를 때 기존 창으로 묻는다.
- CommitReword (새): 막을 까닭 · 확인 글 · 완료 알림 · 새 메시지 다듬기
- GitService.InspectReword / RewordCommit, RewordInfo
- RewordWindow (새): 여러 줄 입력, [바꾸기] 는 기본 단추가 아님
- GitView: MergeHub 첫 우클릭 메뉴, 우클릭한 줄을 먼저 고른다
- 선택이 고친 커밋의 새 해시를 따라간다
- 화면에서 찾아 고침: 새 메시지가 끝 줄바꿈 없이 저장됐다 -> git -m 처럼
다듬는다(뒤 커밋까지 다듬지 않게 새 메시지 하나만)
하네스 MergeSaveTest +40 (272건, 22벌 1,247건) · 빌드 경고 0 · 오류 0.
화면 확인: 되는 자리 1(트리 · 작성자 · 작성 시각 같음, 되돌리기 확인) ·
막는 자리 8 모두 막힘.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
스테이징해 둔 파일이 있으면 그 파일도 이 커밋에 들어간다는 것을, 이미 원격에
올라간 커밋이면 고치는 순간 다음 Push 가 거부된다는 것을 누르기 전에 알린다.
둘 다 걸리면 한 창에 두 줄로 묻고, [아니오] 면 커밋도 메시지 칸도 그대로 둔다.
막지 않고 묻기만 하는 까닭 - 앞선 커밋 수는 마지막 fetch 시점 기준이라
남이 이미 받아 갔는지는 확실히 알 수 없고, 빠뜨린 파일을 같이 넣으려고
일부러 그러는 사람도 있다.
- CommitSelection.AmendWarning: 물을 것이 없으면 null(안 묻는다)
- GitViewModel: 스테이징 수 · 추적 브랜치 · 앞선 커밋 0개인지로 판단
- 하네스 MergeSaveTest +7 (232건, 22벌 1,207건) · 빌드 경고 0 · 오류 0
- 화면 확인(e11-c1g.ps1): 두 줄 다 물음 -> [아니오] 뒤 HEAD · 스테이징 ·
메시지 칸 그대로 -> [예] 뒤 "옛 62dd57f -> 새 6207b26 · 파일 1개 포함",
물을 것이 없는 자리에서는 안 묻고 바로 고침
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
화면에서 여덟 가지를 먼저 재현하고, 방향이 정해진 1 · 3 · 4 · 7 만 고쳤다.
- [마지막 메시지] 는 이력 맨 위가 아니라 HEAD 커밋 메시지를 읽는다 (CommitSelection.MessageOfHead)
- 고쳐 써도 원래 작성자 · 작성 시각을 지킨다 (git 과 같게, 커밋한 사람만 지금)
- 병합 · rebase · cherry-pick · revert 중에는 단추를 끈다 (CanAmend) · 꺼진 까닭을 단추 설명으로
- 알림에 '커밋 수정 완료 (옛 bcd2c43 → 새 fd7810c) · 파일 1개 포함'
- GitWorkspace 가 HeadFullSha 를 들고 있는다
- 하네스 MergeSaveTest +15 (210 → 225), 22벌 1,200건 통과, 빌드 경고 0 오류 0
남은 결정: 2(스테이징 파일이 함께 들어가는 것) · 6(이미 올린 커밋). 8(여러 줄 메시지)은 범위 밖으로 적어 둠.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 결정(2026-09-18): 새 폴더를 만든다 · 쓰다 막히면 먼저 보고 시작한다.
- Services/ExportPlan.cs (새 파일): 폴더 이름(변경분_범위_날짜) · 같은 이름이면 _2 _3 · 쓸 수 있는지 먼저 보기 · 보일 글
- GitService.ExportChangedFiles: 쓰기 전에 막힌 파일을 먼저 보고, 하나라도 있으면 폴더도 만들지 않고 멈춘다
- GitViewModel: 고른 폴더 아래 새 폴더에 뽑고 안내는 그 옆에. 알림에 폴더 이름
- 하네스 ReportTest +12 (45 → 57), 22벌 1,185건 통과, 빌드 경고 0 오류 0
- 화면 확인: 같은 폴더에 두 번 뽑아 _2 가 생기고 기존 파일(메모 · 옛 폴더)은 그대로
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 결정(2026-09-18): 안내는 폴더 밖(옆)에 · 지울 파일은 목록으로만.
- Services/ExportReport.cs (새 파일): 머리글(만든 때 · 사람 · 저장소 · 뽑은 곳 · 범위 두 줄) · 뽑은 파일 목록(추가 · 수정 · 이름 바뀜은 옛 이름 병기) · 장비에서 지워야 할 파일 목록. PathFor 가 폴더 옆 이름을 정함
- GitService.ExportChangedFiles 가 무엇을 어떻게 했는지 목록까지 돌려줌 (IGitService 같이)
- GitViewModel: 뽑은 뒤 안내를 폴더 옆에 쓰고 경로를 로그에. 안내를 못 써도 추출은 성공으로 둔다
- 하네스 ReportTest +14 (31 → 45), 22벌 1,173건 통과, 빌드 경고 0 오류 0
- 화면 확인: 범위 4eb9ece→cbcad8a 안내가 git diff -M 과 같음(뽑은 3 · 지울 2), 병합 커밋은 '(고른 커밋의 부모)' 표시
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 결정(2026-09-18): 제품 기본값 AURORA · C# 파일만 · 저장 동작은 지금 그대로.
- MergeHubSettings.CSharpBraceStyle 기본값 None → Aurora (한 줄, 까닭 주석)
- C/C++ · XAML 은 고칠 것 없음 - CSharpStyle.Applies 가 확장자 .cs 만 본다
- 하네스 StyleTest +12 (78 → 90): 기본값 · 확장자별 적용 여부. 먼저 넣어 기본값 검사만 실패하는 것을 보고 시작
- 설정 파일 없는 첫 실행: 상태바 'C# AURORA' · C# 짝 차이 없음 · C++ 짝 남은 차이 4줄 · 새로 만든 설정에 1
- 웹 문서 매뉴얼 · 설정 표 · 시연 대본의 '기본은 끔' 을 고침
- 22벌 1,159건 통과 · 빌드 경고 0 오류 0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
시험 저장소에 추출용 커밋을 쌓고(새 파일 · 수정 · 삭제 · 이름 바꿈 · 이진 · 한글 깊은 경로 · 되돌림 · 옆가지 병합) 화면에서 사람 순서로 뽑아 git 과 바이트까지 대조.
맞은 것: 파일 고르기(커밋 하나 · 범위 · 병합 첫 부모 · 거꾸로 범위 모두 git 과 같은 목록) · 바이트 보존 · 범위 표시 · 로그
확정된 문제 넷:
- 지운 파일 · 이름 바뀐 옛 경로가 결과에 안 남음 (A-2)
- 무엇과 무엇 사이를 뽑았는지 폴더에 안 남음 (A-2)
- 비어 있지 않은 폴더에 묻지 않고 덮어써 옛 추출이 섞임 (A-3)
- 쓰다 막히면 반쯤 뽑힌 채 멈추고 어디까지 됐는지 모름 (A-3 에 덧)
제품 코드 변경 없음. 시험 도구 세 곳을 고침(별칭 겹침 · 폴더 창 자리 · 창 안 칸 찾기).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
