8차 C-2 기록: cherry-pick 이 원래 작성자를 남기는지 눈으로

제품 코드 변경 없음. 시험 저장소 생성기에서 '상대 쪽 작업' 커밋만 작성자를 박지훈으로 두고
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>

doc/history/2026-09-16-8차.md

@@ -236,3 +236,33 @@ revert 가 충돌을 내려면 되돌릴 줄을 **뒤이어 또 고친 커밋**
 - 자동 조작 쪽: 첫 확인에서 파일 단위 Accept Theirs 가 15개 중 1개만 풀었다(목록 선택이 앱에 안 닿음 - 7차 C-2 와 같은 증상).
   충돌이 0 이 될 때까지 되풀이하도록 스크립트를 고쳐 다시 했다. 제품 결함이 아니다.
 - 제품 코드는 한 줄도 바꾸지 않았다. 7차 C-2 에서 만든 길이 revert 에서도 그대로 동작했다.
+
+## C-2. cherry-pick 이 원래 작성자를 남기는지 눈으로 (2026-09-16, 완료)
+
+7차 C-2 에서는 시험 저장소의 커밋 작성자가 모두 같아(`시험`) **코드로만** 확인했다.
+
+### 시험 재료 (생성기 `C1Repo`, 같은 씨앗)
+
+`상대 쪽 작업` 커밋만 **다른 사람이 쓴 것**으로 뒀다 — 작성자 `박지훈 <jihoon@localhost>` · 커밋한 사람 `시험 <test@localhost>`.
+저장소의 `user.name` 은 그대로 `시험` 이라, 앱이 커밋하면 커밋한 사람은 `시험` 이 된다.
+
+### 확인한 것 (같은 저장소를 새로 만들어, MergeHub 와 git 을 따로)
+
+| 무엇 | 작성자 | 커밋한 사람 |
+|---|---|---|
+| 가져올 커밋 (`상대 쪽 작업`) | **박지훈** `<jihoon@localhost>` | 시험 |
+| **MergeHub** cherry-pick → [커밋] | **박지훈** `<jihoon@localhost>` | 시험 `<test@localhost>` |
+| **git** cherry-pick (사본에서 같은 순서) | **박지훈** `<jihoon@localhost>` | 시험 `<test@localhost>` |
+| **MergeHub** revert → [커밋] | 시험 `<test@localhost>` | 시험 `<test@localhost>` |
+| **git** revert (사본에서) | 시험 `<test@localhost>` | 시험 `<test@localhost>` |
+
+**둘이 같다.** cherry-pick 은 원래 작성자를 남기고 커밋한 사람만 지금 사용자로 바뀐다. revert 는 둘 다 지금 사용자다 — git 과 같은 규칙이다.
+
+이력 목록에도 그 커밋이 `상대 쪽 작업 dddd515 · 박지훈` 으로 보여, 고를 때 누가 쓴 것인지 화면에서 읽힌다.
+
+제품 코드는 바꾸지 않았다.
+
+### 남긴 것
+
+- 자동 조작 쪽: git 으로 revert 를 견줄 때 **MergeHub 가 이미 revert 한 뒤의 저장소를 복제해** git 이 되돌릴 것이 없었다.
+  저장소를 새로 만들어 git 쪽만 다시 쟀다(위 표의 값).

doc/history/changelog.md

@@ -8,6 +8,7 @@
 
 | 날짜 | 항목 | 커밋 |
 |---|---|---|
+| 2026-09-16 | **8차 C-2** — 7차에서 코드로만 봤던 "cherry-pick 은 원래 작성자를 남긴다" 를 화면으로 확인(제품 코드 변경 없음). 생성기에서 상대 쪽 작업 만 작성자를 박지훈으로 두고, MergeHub 와 git 이 각각 cherry-pick · revert 를 하게 해 견줌 — cherry-pick 은 둘 다 작성자 박지훈 · 커밋한 사람 시험, revert 는 둘 다 시험. 이력 목록에도 박지훈으로 보인다 | 아래 |
 | 2026-09-16 | **8차 C-1** — 7차 C-2 에서 만든 길로 revert 도 되는지 화면으로 끝까지 봤다(제품 코드 변경 없음). 시험 저장소 생성기에 eature/revert(뒤이은 수정) 갈래를 더해 revert 충돌 16개를 만들고, [Revert] → 머리 "revert 진행 중" → 네 칸 REMOTE "되돌리는 커밋 …" → 로그 "101행 Theirs(커밋 …) 반영" → 진행 줄 "[커밋] 으로 revert 를 끝냅니다" → 원래 메시지로 커밋까지. 줄끝 · BOM 바뀐 파일 0 · 충돌 표식 0 · class 이름 검사 0 | 아래 |
 | 2026-09-16 | **8차 B-3** — 네 칸 MERGED 칸 줄 번호가 정렬할 때 정해진 채 굳어, 고른 줄 · 머지 주석으로 결과가 늘어도 그대로였다(끝 번호 3363 · 상태바 총 3369줄). 사용자가 "결과 파일 번호로" 를 골라, 결과에 들어가는 줄만 1부터 다시 매긴다(MergedNumbering). 줄을 만들 때와 요약을 그릴 때마다 다시 매겨 고르기 · 편집 · 되돌리기 뒤에도 맞는다. 저장된 파일 줄 수(3369)와 화면 번호가 같아짐 | 아래 |
 | 2026-09-16 | **8차 B-2** — 이미 들어 있는 커밋을 cherry-pick 하면 [커밋] 이 켜지는데 누르면 로그에 "실패: No changes; nothing to commit." 만 남고 진행 줄도 그대로라 같은 단추를 또 누르게 됐다. 커밋할 것이 있는지(HasStagedChanges)를 상태로 들고 있다가 [커밋] 을 끄고, 진행 줄 · 적용 로그가 "가져올(되돌릴) 변경이 없습니다 - [작업 취소] 로 끝냅니다" 라고 말한다. 커밋 직전에도 사람 말로 막는다. 병합 커밋은 트리가 같아도 정상이라 걸지 않음 | 아래 |

doc/진행상황.md

@@ -214,7 +214,7 @@
 | 상태 | 항목 |
 |---|---|
 | **완료** | C-1 revert 충돌을 화면으로 끝까지 — 생성기에 `feature/revert` 갈래를 더해 충돌 16개를 만들고, MergeHub 만으로 [Revert] → 네 칸("되돌리는 커밋 …") → [커밋] 까지. 원래 메시지 `Revert "내 쪽 작업"`, 줄끝 · BOM 바뀐 파일 0, 제품 코드 변경 없음 |
-| 대기 | C-2 cherry-pick 이 원래 작성자를 남기는지 눈으로 |
+| **완료** | C-2 cherry-pick 이 원래 작성자를 남기는지 눈으로 — 생성기에서 상대 쪽 커밋만 작성자를 박지훈으로 두고 확인. MergeHub cherry-pick 은 작성자 박지훈 · 커밋한 사람 시험, revert 는 둘 다 시험 — git 과 같음. 제품 코드 변경 없음 |
 | 대기 | C-3 창 크기 조절에서 안 본 것 — 스냅 · 첫 Win+↓ 크기 · 덮는 창 가운데 · 1px 테두리 (플랫폼) |
 
 ### D. 문서