기록에서 삭제하지 않고 변경 사항 포기


180

방금 작동하지 않은 커밋이 있으므로 history에서 삭제하지 않고 버리고 싶습니다 .

이전 개정판에서 업데이트하여 커밋하여 새로운 헤드를 만들었습니다.


나는 가지가없고, 가지를 원하지 않습니다. 단지 새 머리를 그대로 그대로, 공상, 합병, 걱정하지 않고 그냥 이전 머리를 잊어 버리고 싶습니다.

나는 그것을하는 방법을 찾지 못하는 것 같아서 할 수 없다는 것을 믿기 시작했습니다. 내가 찾은 것은 가지에 관한 것, 또는 병합에 관한 것입니다.


1
리포지토리에 있으므로 기록에서 삭제되지 않았습니다. 새 헤드를 만들었으므로 실수없이 수정을 계속할 수 있습니다. 새로운 머리로 계속 진행하는 데 방해가되는 것은 무엇입니까?
— ataylor

가지에 대한 혐오감은 무엇입니까?
— Andres Jaan Tack

@Andres 그것은 가지에 대한 혐오가 아닙니다. 방금 닫으려면 하나를 만드는 어리석은 추가 단계없이 작동해야했습니다.
— o0 '.

누구나 읽을 수 있습니다-이 시나리오에서 브랜치가 이미 생성되었습니다. 이 답변에 제공된 설명에 유의하십시오. stackoverflow.com/a/3692607/3195477
— UuDdLrLrSs

답변:


181

잊고 자하는 개정으로 리포지토리를 헤드로 업데이트 한 다음 hg commit --close-branch(익명) 브랜치를 닫힌 것으로 표시하는 데 사용하십시오 . 그런 다음 그 지점의 머리로 업데이트 할 원하고 작업을 계속합니다.

-c옵션을 사용하면 닫힌 분기를 볼 수 hg heads있지만 기본적으로 표시 hg merge되지 않으며 닫힌 헤드와 병합을 시도하지 않습니다.

당신은 사용해야합니다 hg push --force당신이 누를 때 당신이 실제로 원격 저장소에 추가 머리를 만들 수 있기 때문에 다른 저장소에이 폐쇄 머리를 밀어 처음. 따라서 Mercurial에게 이것으로 괜찮다고 말하십시오 --force. 닫힌 머리를 당기는 사람들은 경고로 귀찮게하지 않습니다.


3
@Niall C. 그가 그것을 지명 지점으로 표시 한 경우에만 작동하지 않습니까? 나는 그가 말한 것을 기본으로하고 있다고 가정하고있다
— msarchet

하지만 ... 사실이 아닙니다. 전화 할 때 여전히 두 명의 헤드가 모두 표시됩니다. 나는 hg heads수은 1.4.3을 사용하고 있습니다. 이것이 새로운 기능입니까?
— o0 '.

2
@msarchet : AFAIK, 오늘 시도해보십시오. --close-branch는 익명 브랜치에서 작동하지 않습니다. 해야하지만 그렇지 않습니다. 향후 버전의 Mercurial에서이 변경 사항이 적용되기를 바랍니다. 익명의 브랜치는 매우 훌륭하지만 명명 된 브랜치만큼 일류이어야합니다.
— Krazy Glew

4
@KrazyGlew : 문제는 "익명 (anonymous)"브랜치는 실제로 그 기반이 된 브랜치와 이름이 같은 두 번째 브랜치라는 것입니다. 실제로 (이름이 지정된) 브랜치를 닫으려고하는 것이 아닙니다. 변경 한 내용을 버리고 있습니다. 다시 말해, hg branches현재 사용중인 지점 이름을 표시해야합니다. 지점을 닫으려고하지 않고 익명 지점을 원래 지점으로 다시 병합하여 모든 변경 사항을 삭제하십시오.
— StriplingWarrior

2
필자의 경우 default (이것은 표준 임)라는 브랜치와 default / master라는 다른 브랜치가 있습니다 (원격 저장소가 실제로 git이기 때문에 생각합니다). hg 업데이트 기본 / 마스터; hg commit --close-branch; hg 업데이트 기본값이 저에게 효과적이었습니다.
— MattD

68

이 단계에서 브랜치로 작업 하고 싶지 않다는 것을 알고 있지만 이것이 바로 당신이 한 일입니다. 이전 버전으로 돌아가서 작동하는 무언가를 커밋하면 이름이없는 분기가 만들어 지지만 분기는 모두 동일합니다.


머리를 여러 개 갖는 것에 대해 걱정하지 않고 그대로 유지하는 데 아무런 문제가 없지만 물건을 정리하고 싶다면 실수로 잘못된 머리를 한 번 선택하지 않으면 이전 지점을 죽일 수 있습니다.

Mercurial 문서에는 가지 치기 데드 브랜치 (Pruning Dead Branches) 와 관련된 여러 옵션을 안내하는 좋은 섹션이 있습니다 .

가장 좋은 방법은 오래된 지점을 "닫은"것으로 표시하는 것입니다. 이전 헤드가 "123"개정판 인 경우 :

hg update -r 123
hg commit --close-branch -m 'Closing old branch'
hg update -C default

3
Blurgh-입력 한 후 @Niall의 답변을 보았습니다. Niall을 공표하고 제로 포인트 풀에서 내 언어가 고갈 될 수 있습니다. :)
— Nick Pierpoint

1
당신의 대답처럼 나는 더 덜 merucrial의 용어 (같은 근처 내가 말할 수있는 자식 사용자를 혼란스럽게 선택되어야한다 보인다) groking 필요
— tacaswell

8
롤 반대 야! 수은의 용어는 svn 사용자에게 자연스럽게 들리도록 선택되었지만 git의 용어는 지옥과 혼동됩니다! 어쨌든,이 대답을 upvoting하면 마지막 업데이트 -C 포함되어 있기 때문에
— Tobia

2
당신은 왜 필요합니까 -C에서 hg update? 파일이 수정되지 않은 것으로 보이므로 파일이 없으면 작동합니다.
— 최대

1
내가 알 수있는 한 어디에서나 -C가 필요하지 않습니다. 그러나 업데이트하려고 할 때 눈에 띄는 변경 사항이 있으면 중단됩니다.
— Eli Albert

21

먼저 다음을 입력하십시오.

hg heads

세 개의 머리가 나열되어 있다고 상상해보십시오.

changeset:   223:d1c3deae6297
user:        Your name  <your@email.com>
date:        Mon Jun 09 02:24:23 2014 +0200
summary:     commit description #3

changeset:   123:91c5402959z3
user:        Your name <your@email.com>
date:        Sat Dec 23 16:05:38 2013 +0200
summary:     commit description #2

changeset:   59:81b9804156a8
user:        Your name <your@email.com>
date:        Sat Sep 14 13:14:40 2013 +0200
summary:     commit description #1

마지막 머리를 활성 상태로 유지하고 (223) 나머지를 닫으려고합니다.

그런 다음 다음과 같이하십시오.

클로즈 헤드 # 59

hg up -r 59
hg ci --close-branch -m "clean up heads; approach abandoned"

클로즈 헤드 # 123

hg up -r 123
hg ci --close-branch -m "clean up heads; approach abandoned"

변경 사항을 커밋

hg push

마지막에 오른쪽 머리로 전환하는 것을 잊지 마십시오

hg up -r 223

그리고 당신은 끝났습니다.


이것은 훌륭한 튜토리얼이지만 커밋 메시지 예제는 약간 메타입니다. 나는 당신에게서 배우는 사람들이 더 나은 커밋 메시지를 제공 할 수 있도록 더 나은 예제를 포함시킬 것입니다. 같은 것 --close-branch -m "Closing branch - technique #2 abandoned in favor of technique #3".
— Jason R. Coombs

5
또한 작업 복사본이 여전히 닫은 머리에 있다는 점을 제외하고는 마지막에 끝났습니다. 닫힌 헤드에서 다른 변경 사항을 적용하면 다시 열립니다. hg up -r 223변경하기 전에 원할 것 입니다.
— Jason R. Coombs

@Jason R. Coombs : 그렇습니다!
— Artur Barseghyan

@Niall에 따르면, 지금 내 자신의 경험에 따르면 여러 헤드를 밀고 있다는 경고 를 넘어서는 hg push --force것이 아닙니다 hg push.
— craq

1
@Artur 나는 일반적으로 동의합니다. 이 경우 hg push자체로는 저에게 효과가 없었습니다. 여러 헤드로 인해 거부되는 경우 외부 리포지토리로 변경 사항을 적용하는 것이 좋습니다.
— craq

12

사용하고 싶습니다 hg backout. 이렇게하면 변경 세트에서 변경 한 사항이 모든 하위 변경 세트에서 제거됩니다.

좋은 설명을 위해 이것을 확인하십시오. 머큐리얼 백 아웃


2
이것은 정답입니다. 백 아웃은 변경 세트의 역수를 추가하여 작업을 취소하고 아이디어가 마음에 들지 않은 이유를 상기시키는 커밋 메시지를 제공합니다.
— Ry4an Brase

7
나는 실제로 동의하지 않는다. 한 헤드에서 작업을 포기하고 좋은 출발점에서 다시 시작하는 것은 백 아웃을 사용하는 것보다 깨끗한 작업 패턴처럼 보인다. 특히 한 번에 둘 이상의 변경 세트를 제거 할 수 없기 때문입니다.
— Martin Geisler

1
가이슬러 @Martin 잘 그는 가지 않고 변경 포기하고 싶어 나는 일반적으로이 동의하지만, OP는 말했다
— msarchet을

2
@Martin Geisler
— 그렇습니다.

1
때로는 유용 할 수도 있지만 실제로는 원하는 것이 아니 었습니다. 어쨌든 고마워 :)
— o0 '.

2

Niall과 Nick의 대답은 모두 직설적입니다. 매달린 머리를 많이 만들었으므로 머리를 더 쉽게 닫을 수 있도록 별칭을 작성했습니다. 이것을 당신의 .hgrc:

[alias]
behead = !REV=$($HG id -i); $HG update $@ -q && $HG ci --close-branch -m "Closing dead head" && $HG update $REV -q

(이미 [alias]섹션이 있다면 대신 추가 할 수 있습니다)

이제 다음과 같이 하나의 단일 명령으로 헤드를 닫을 수 있습니다 (다른 변경 세트로 수동으로 업데이트하지 않아도 됨).

$ hg behead 123

참고 : 별명은 Mercurial 별명이 쉘 명령 일 수 있다는 사실을 이용 합니다 . 이것은 아마도 Windows가 아닌 UNIX에서만 작동한다는 것을 의미합니다.


2

원치 않는 분기를 닫거나 제거하는 대안 은 효과를 완전히 버리는 방식으로 병합 하지만 히스토리에는 남겨 두는 것입니다. 이 접근 방식은 원치 않는 변경 사항이 푸시로 전파되도록 허용하므로 의도 된 효과 인 경우에만 사용하십시오.

변경 세트 이력이 다음과 같다고 가정 해 봅시다.

1-2-3-4-5-6    
       \    
        7-8-*

그것은이다 5과 6더 이상 어떤 싶어하지 않습니다.

당신은 이것을 할 수 있습니다 :

hg up 8
hg merge -r 6 -t :local
hg commit ...

이것은 이것을 만들 것입니다 :

1-2-3-4-5-6    
       \   \
        7-8-9-*

업데이트를 8통해 원하는 히스토리 헤드에서 작업 할 수 있습니다.

-t :local에 지시라는 병합 "도구"를 사용 HG 지역 즉, 다른 지점에서 변경, 현재 작업 폴더 상태로 표현하지 사람을 무시한다는 뜻입니다. 더 많은 정보 .

따라서 원치 않는 변경 사항 5과 6기록은 유지되지만 최근에는 영향을 미치지 않습니다.


2

이것은 Evolve 확장 의 사용 사례입니다 . 현재 Mercurial과 함께 제공되지 않으므로 기술적으로 타사 확장입니다. 그러나 Mercurial 개발자를 포함하여 많은 사람들이 상당히 많이 사용하고 있으며 매우 적극적으로 개발되고 있으며 아무데도 가지 않습니다.

Evolve 확장을 사용하면 간단히

hg prune -r revname

그리고 당신의 인생을 계속합니다. cset은 여전히 ​​존재하지만 더 이상 사용되지 않습니다. --hidden옵션을 Mercurial 명령에 전달하지 않으면 표시되지 않으며 기본적으로 원격 저장소로 푸시되지 않습니다. 당신이 정말로 원한다면 그것을 강요 할 수 있다고 생각하지만.

정리할 cset에 유지하려는 조상이 hg evolve있는 경우 해당 변경 세트를 리베이스 하기 위해 실행해야합니다 . hg evolve자동으로 수행됩니다. 그렇지 않으면 아무것도 할 필요가 없습니다.


1

원치 않는 머리를 복제하지 않고 손상된 저장소를 새 것으로 복제 할 수 있습니다. 그런 다음 이전 저장소를 제거하고 새로 작성된 복제본을 원래 위치로 이동 한 후 계속 작업하십시오. 시간이 다소 걸리지 만 원치 않는 개정의 표시없이 완벽하게 깨끗한 저장소를 얻을 수 있습니다.

hg clone --rev myGoodResition myDirtyRepo myCleanRepo

1
이것은 내가 요청한 것이 아닙니다. 죄송합니다.
— o0 '.

4
@ 크리스토프 : 농담입니까? 내 게시물 의 첫 번째 줄 을 다시 읽 습니다. " 기록에서 삭제하지 않고
— 버립니다

-1

오류로 생성 된 헤드를 참수하고 싶을 때이 문제가 여러 번 발생했습니다. 나는 항상 그것이 지구의 얼굴에서 사라지는 것을보고 싶다.

지역 사본에서 최신 정보를 구한 후 다음을 수행하십시오.

  1. 벗길 머리의 시작 부분을 찾고 (새 목이 갈라지기 시작하는 곳) 개정 번호를 얻습니다.

  2. 벗겨


출처 : TipsAndTricks .

출처 : PruningDeadBranches # Using_strip .

hg --config extensions.hgext.mq= strip -n <rev>
  1. 간단한 파일 업데이트 (파일에 공백 추가)를 만들고 커밋하고 푸시합니다.

이제 리포지토리에 머리가 벗겨 져야합니다. 제거는 중앙 저장소로 푸시 할 수있는 변경 사항을 작성하지 않으므로 마지막 단계는 중요합니다. 마지막 단계가 없으면 머리를 로컬에서 벗겨 낸 것뿐입니다.


1
그러나 푸시하면 원격 저장소에서 아무것도 삭제되지 않습니다. 정보 만 추가 합니다. 변경 세트가 이미 중앙 리포지토리에있는 경우에는 진화 확장을 사용하거나 중앙 서버 자체에서 변경 확장을 사용해야합니다. 변경 세트가 아직 중앙 리포지토리에없는 경우 로컬로 제거하면 푸시가 필요하지 않습니다.
— Ben
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.