커밋을 되돌릴 때 'git subtree split'실패하는 법?

Question

this mailing list post에 설명 된 문제가 발생합니다. 'git subtree split'은 되돌리기 커밋 다음에 병합 커밋이있는 경우 기록을 재구성하지 못합니다. 나는 약간 자신의 메일 링리스트 게시물에 파비앙에서 제공하는 테스트 스크립트를 조정 한 :

git init 

# create a directory that is going to be split 
mkdir doc 
echo "TEST" > doc/README 
git add doc 
# commit A 
git commit -a -m"first version" 

# create a branch with a new commit (Z) 
git checkout -b test 
echo "TEST" > doc/README1 
git add doc/README1 
git commit -a -m"added README1" 
git checkout master 

# modify the README file (commit B) 
echo "TEST_" > doc/README 
git commit -a -m"second version" 

# revert the change (commit C) 
echo "TEST" > doc/README 
git commit -a -m"revert second version" 
# or use git revert HEAD^ 

# split 
git subtree split --prefix="doc" --branch=TARGET 

# add another commit (to a file *not* in the subtree dir) 
echo "BLA" > BLA 
git add BLA 
git commit -a -m"third version" 

# adding another commit to a file in the subtree dir will "fix" things 
#echo "MEH" > doc/MEH 
#git add doc 
#git commit -a -m"fourth version" 

# the log will show the 3 commits as expected (including B and C) 
GIT_PAGER= git log --oneline TARGET 

# merge the test branch 
git merge -m"merged test" test 

# attempt to re-split; this will fail 
git subtree split --prefix="doc" --branch=TARGET 

# see what history split generates 
git subtree split --prefix="doc" --branch=TARGET2 

내가 그 서브 트리 디렉토리의 변화를 만들어 커밋 되돌리기가 다른 뒤에 커밋 경우 예상대로 분할이 작동 것을 발견했다

(위의 "제 4 판"참조). git-subtree의 버그처럼 보입니다.

그러나 제 경우에는 병합이 이미 수행되었으므로 더미 커밋을 추가하여 문제를 해결할 수 없습니다. 이것 주위에 다른 방법이 있습니까? 아마도 git-subtree 소스 코드에 대한 빠른 픽스 패치일까요?

Answer 1

나는 무슨 일이 일어나고 있는지 알 것 같아. 두 브랜치 중 하나에서 순수한 변경이 없다면, 병합 커밋의 ID는 다른 브랜치의 마지막 커밋의 ID와 동일 할 것입니다 (옵션을 git subtree split 명령에 전달하여 분할의 새 커밋 ID를 확인하십시오). 아웃 커밋). 이 경우 git-subtree는 병합 커밋을 삭제합니다. 정규 커밋의 경우 커밋이 하위 트리 디렉터리의 파일을 변경하지 않기 때문에이 작업이 수행됩니다.

해결책은 단순히 병합 커밋을 복사하려면 copy_or_skip 함수를 조정하는 것이라고 생각했습니다. 그러나 이로 인해 생성 된 커밋 기록이 이전과 다를 수 있으며 (불필요한 병합 커밋이 이전에 없어져서) 다른 문제가 발생할 수 있습니다.