커밋 된 Mercurial 변경 집합에서 하나의 점선을 수정하는 가장 간단한 방법은 무엇입니까?

Question

커밋 된 changeset의 작은 버그를 사실 이후에 찾아내는 유스 케이스로 자주 들어가서 changeset를 되돌릴 수있는 옵션이 없습니다.

는/그 내보내기/가져 오기하는 것은 그것의보다 훨씬 더 학대

나는 그러나 하나이 "간단한"사용 사례가 적용되지 않습니다 similar questions 및 the Mercurial docs for graft 및 general advice on backporting changes을 검토 한 결과, 또는이 DVCS의 리베이스/복제의 복잡한 소택지에 포섭 것입니다 사소한 작업 인 것처럼 보일만한 가치가 있습니다.

A -> B -> C -> D -> E 

이루어진 저장소 요컨대

여러 파일을 변경하는 다수 구성 변경 집합 B에 하나 개의 파일에 필요한 고정 한줄 버그있다. 되돌리기/고정/다시 적용하지 않고이 작업을 수행 할 수있는 방법이 있습니까? 그냥 할 수있게

... -> B -> B' -> C -> ... 

이 문제를 해결할 것입니다.

리베이스의 컨텍스트에 대한 컨텍스트가 제로이므로 숟가락 피드를 기꺼이 사용하지 않으면 훨씬 도움이되지 않습니다. 내 요구는 대개 매우 간단합니다. 필자는 기본적으로 단일 사용자 모드에서 RCS 또는 SVN의 고급 형식으로, 일반적으로 커밋, 분기 및 병합 (절대적으로 푸시, 가져 오기, 내보내기, 리베이스 또는 다른 '분산'기능 없음) 만 사용합니다. 예,이 문제를 해결하기위한 여러 가지 옵션을 잠재적으로 배제하고 있음을 알고 있습니다 만, 사용하지 않는 Mercurial 기능의 미세한 동작을 이해하는 것이 아니라 내 코드를 수정하는 데 중점을 둡니다. (죄송합니다. 정직합니다.)

이것이 가능하지 않은 경우 알려 주시면 수정 세트 B에서 E를 거친 커밋 메시지로 F로 수정 프로그램을 커밋 할 수 있습니다.

Answer 1

이미 다른 사용자에게 변화를 추진했다면, 당신이 염두에 C, D의 변경 집합 ID를 유지하지 않은 경우 단순히 F.

로

을 커밋 권합니다, ... 모두 바뀔 것이다. 따라서 커밋 해시가 C ', D', ...가됩니다.

새로운 'hg evolve'기능이 사용자가 요구하는 것에 매우 잘 작동한다는 것을 알게되었습니다.

작은 경고 : 진화는 지금도 여전히 실험적입니다. 백업이 있어야합니다! 그러나 진화는 실제로 이것이 가장 적합한 것처럼 보입니다.

먼저 setup instructions을 따르십시오. B에

1. 업데이트 : hg update -r B
2. 이 변경 사항을 확인

   그런 다음, 다음 단계를 수행 할 수 있습니다.

3. 수정 된 변경 집합을 적용하십시오. hg commit --amend 불안정한 변경 집합 (B의 하위 집합 인 모든 변경 집합)에 대한 경고가 표시됩니다.
4. 실행 hg evolve --all. 이렇게하면 C, D, ...가 B '의 꼭대기를 기준으로 올바르게 수정됩니다.

Answer 2

내 경험으로는 자식이 아니라 수은이 아니기 때문에 명령이 옳지 않을 수 있습니다. 네가하고 싶은 것은 네, 때로는 DVCS 랜드에서 "리베이스"라고 부릅니다.하지만 저는 다른 버전 컨트롤에서 왔습니다. 그래서 저는 이것을 "rebase"라고 생각하지 않습니다. 나는 단지 그것을 "역사를 다시 쓰는"것으로 생각한다. 그것은 단지 몇 가지 명령입니다.

스푼 피드, 어? (? 그것은 HG와 함께 제공되지만 사용할 수 없습니다 것 같다)

1. 가 수 있도록
2. hg up B 다음은 비행기 ...
   내가 당신의 명령을 이런 식으로 뭔가를 갈 생각 온다
   • B에 대한 수정 사항 : 코드에서 B와 동일하게 만듭니다.
   • 나는 명령이 올바르습니까? 이 작업은 기본적으로 작업 디렉토리가 B 지점에서 작동하도록 소스에서 설정해야합니다.

3. ... B를 수정하고 커밋 세트를 커밋합니다. 변경 사항 트리는 다음과 같습니다.

   A -> B -> C -> D -> E 
        \ 
        -> FIX <--- you are here 
   

   자, 이제는 다시 쓰는 역사 부분이 있습니다. E에 이르는 변경 내역을 가져오고 A->B 대신에 A->B->FIX을 기반으로 한 것처럼 다시 쓰려고합니다.

4. hg up E가 후속 변경을하고 순차적으로 적용 할 수 있도록
5. hg rebase --dest FIX
   • HG가, B가 공통 조상 것을 알고 똑똑 (이것은 당신이 재 작성에 관심있는 코드 라인이기 때문에).

그렇습니다. (요청에 따라)이 후, 당신의 역사는 다음과 같이 표시됩니다

A -> B -> FIX -> C' -> D' -> E' 

나는 등 C'로 쓴, 그것은 그 지점에서 소스가 이전보다 다를 수 있음을 이해하는 것이 중요하기 때문에 : 특히, 그들은 FIX의 설립을 반영합니다. 코드가 변경 세트 에 의해 변경된 내용은 수정 사항과 충돌 또는 기타 겹침이없는 한 C', D', E'에서 변경된 내용과 동일해야합니다.이 경우 변경 사항의 응용 프로그램과 수동으로 상호 작용해야합니다.

예를 들어, 수정 프로그램의 영향을받는 코드의 리팩터는 변경 사항 수정이 올바르게 리팩토링되도록하는 것을 의미 할 수 있습니다. 버전 관리 시스템이 파일 간의 코드를 추적 할 수없는 경우이 연습의 또 다른 인스턴스를 의미 할 수도 있습니다.

중요 : 어쩌면 : 누군가 다른 사람이 내 repo에서 변경 내용을 추적하고 원래 변경 집합을 가져온 경우이 작업을 수행하면 일부 기록이 사라져서 정말 엉망이 될 수 있습니다. 사람들이 비명을 지르며 "rebase"에 대한 온라인 머리카락을 꺼내는 것을 보는 이유입니다.

Answer 3

"덤프"하고 확실한 방법 :

• hg up B
• 수정
• hg commit
• hg up E
• hg merge (갈등 해결 가능)와

즉 Y 이제 B의 자식으로 수정 (익명의 브랜칭 및 현재 브랜치에서 헤드 변경 세트 F)하고 F를 E로 병합 (G 변경 세트로)하여 F 변경 사항을 메인 라인으로 가져옵니다. 당신은 E : 병합의 방향을 건너 뛸 수 있습니다. 익명의 브랜칭은별로 의미가 없습니다.