Hg : git의 rebase와 같은 rebase를 수행하는 방법

Hg : git의 rebase와 같은 rebase를 수행하는 방법

---

힘내에서 나는 이것을 할 수있다 :

1. 새로운 기능에 대한 작업을 시작하십시오.
$ git co -b newfeature-123 # (로컬 기능 개발 지점)
몇 가지 커밋을 수행하십시오 (M, N, O)

마스터 A --- B --- C
                \
새로운 기능 -123 M --- N --- O

2. 업스트림 마스터에서 새로운 변경 사항을 가져옵니다.
git pull
(ff 커밋으로 업데이트 된 마스터)

마스터 A --- B --- C --- D --- E --- F
                \
새로운 기능 -123 M --- N --- O

3. 새로운 기능을 갖도록 마스터를 리베이스 해제 
최신 업스트림 변경에 대비하여 개발할 수 있습니다.
(newfeature-123에서)
$ git rebase 마스터

마스터 A --- B --- C --- D --- E --- F
                            \
새로운 기능 -123 M --- N --- O

Mercurial에서 동일한 작업을 수행하는 방법을 알고 싶습니다. 웹에서 답변을 찾아 보았지만 찾을 수있는 최선의 방법은 다음과 같습니다 .git rebase-hg do it

그 링크는 2 가지 예를 제공합니다 :
1. 나는 이것을 인정할 것입니다 :

hg -CF  
hg 지점 -f newfeature-123  
HG 이식 -a -b newfeature-123 

pre-rebase MNO를 병합되지 않은 헤드로 남겨두고 업데이트 된 메인 라인에서 분기하는 것을 나타내는 3 개의 새로운 커밋 M ', N', O '을 생성한다는 점을 제외하고는 나쁘지 않습니다.

기본적으로 문제는 내가 이것으로 끝내는 것입니다.

마스터 A --- B --- C --- D --- E --- F
                \ \
newfeature-123 \ M '--- N'--- O '
                  \
새로운 기능 -123 M --- N --- O

삭제해야 할 로컬, 원치 않는 커밋 뒤에 남겨지기 때문에 이것은 좋지 않습니다.

2. 동일한 링크의 다른 옵션은

hg qimport -r M : O
hg qpop -a
H를 위로
hg 지점 newfeature-123
hg qpush -a
hg qdel -r qbase : qtip

and this does result in the desired graph:

master A---B---C---D---E---F
                            \
newfeature-123               M---N---O

but these commands (all 6 of them!) seem so much more complicated than

$ git rebase master

I want to know if this is the only equivalent in Hg or if there is some other way available that is simple like Git.

---

VonC has the answer you're looking for, the Rebase Extension. It is, however, worth spending a second or two thinking about why neither mq nor rebase are enabled by default in mercurial: because mercurial is all about indelible changesets. When I work in the manner you're describing, which is nearly daily, here's the pattern I take:

1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)

master A---B---C
                \
newfeature-123   M---N---O

2. Pull new changes from upstream mainline:
$ hg pull

master A---B---C---D---E---F
                \
newfeature-123   M---N---O

3. merge master into my clone so that my new feature 
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F

master A---B---C---D---E---F
                \           \
newfeature-123   M---N---O---P

and that's really all that's necessary. I end up with a newfeature-123 clone I can easily push back to the mainline when I'm happy with it. Most importantly, however, I never changed history. Someone can look at my csets and see what they were originally coded against and how I reacted to changes in the mainline throughout my work. Not everyone thinks that has value, but I'm a firm believer that it's the job of source control to show us not what we wished had happened, but what actually happened -- every deadend and every refactor should leave an indelible trace, and rebasing and other history editing techniques hide that.

Now go pick VonC's answer while I put my soapbox away. :)

---

You might be looking for Rebase Extension. (implemented as part of the SummerOfCode 2008)

In those cases it can be useful to "detach" the local changes, synchronize the repository with the mainstream and then append the private changes on top of the new remote changes. This operation is called rebase.

Getting from:

to:

---

As commented below by steprobe:

In the case where you aren't pulling the changes in, and you have the two branches in your repo, you can do (using keepbranches):

hg up newfeature-123 
hg rebase -d master --keepbranches

(--keepbranches: Inherit the original branch name.)

Mojca mentions:

I like using hg rebase --source {L1's-sha} --dest {R2's-sha}, but I didn't know I could add --keepbranches at the end.

As illustrated below by Jonathan Blackburn:

 hg rebase -d default --keepbranches

---

Assuming you have a modern Hg installation, you can simply add:

[extensions]
rebase = 

to ~/.hgrc.

Then you can use the commands hg rebase, hg pull --rebase, or hg help rebase.

---

I don't think the answers above achieve the OP's goal, which was to maintain his task branch, just rebased against a later point on the parent branch.

Let's say I start with this graph (generated using the graphlog extension. Serious geek love for graphlog).

@  9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o  af630ccb4a80 default againagainagain  
| |
o |  98bdde5d2185 Feature 3 branch commit 1  feature3
|/
o  e9f850ac41da foo   

If I'm on the feature3 branch and want to rebase it off of the againagainagain commit, I understand that I would run hg rebase -d default. This has the following result:

@  89dada24591e Feature 3 commit 2 tip 
|
o  77dcce88786d Feature 3 branch commit 1  
|
o  af630ccb4a80 default againagainagain  
|
o  e9f850ac41da foo  

Mission accomplished? I don't think so. The problem is that when the commits on the feature3 branch were rebased on againagainagain, the feature3 branch was deleted. My commits have been moved to the default branch, which was what I was trying to avoid in the first place.

In Git, the result would look like this:

@  9a4c0eb66429 Feature 3 commit 2 tip
|
o  98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o  af630ccb4a80 default againagainagain
|
o  e9f850ac41da foo

Notice that the feature3 branch still exists, the two commits are still on the feature3 branch, and not visible on default. Without preserving the task branch, I don't see how this is functionally different from a merge.

UPDATE: I discovered the --keepbranches flag supported by hg rebase, and I'm happy to report everything is okey-dokey. Using hg rebase -d default --keepbranches, I exactly replicate the Git behavior I craved. A couple of aliases later and I'm rebasing like nobody's business.

---

Since some people have chimed in saying they think it's good to keep every iteration of everything, I'll point out that for larger open-source projects, accepting changes full of merges and development iteration would make for a messy mainline revision history, and make the revision history less useful for seeing how the current version got there.

This works well when submitted changes are reviewed by people that didn't write them, before they're accepted, so changes that do go into the mainline are generally debugged and working. Then when you backtrack to the origin of a line, you see all the changes that go with it, not some point in the middle of development of the change it's part of.

The x265 contributors page explains how to re-commit a set of changes you're working on, to get them ready for submission to the x265 project. (Including use of TortoiseHG to commit some but not all changes in an individual file, like git gui's stage/unstage diff hunk for commit).

The process is to get hg updated to the upstream tip, and then get all your changes uncommitted in the working directory. Shelve any that aren't part of what you want to submit, then break the rest into as many separate commits are appropriate, with nice commit messages.

I guess you'd copy/paste and then edit commit messages from previous iterations of a patchset that you're revising. Or maybe you could graft your old commits (cherry-pick in git language), and then amend them one by one, to get your old commit messages as a start point for editting.

참고URL : https://stackoverflow.com/questions/2672351/hg-how-to-do-a-rebase-like-gits-rebase