Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can I make an older revision the tip and push (using Mercurial)?

Say if I have a good revision: 3200. Then I want to test something, and since it has 10 lines of change, and I need to remove a few lines, even though I am still testing I commit first, and after some changes, commit again, and let's say, I did 6 commits.

Now I want to put this on hold, but I don't want to lose all the testing and code written, so I want to

$ hg up -r 3200

which is the good, stable revision I want, and now can I commit and push as the tip? (if possible I want to avoid backing out hg backout because it looks bad somewhat, and I don't want to rollback because rollback has side effect of "if someone pulled from me during this time, the change can somehow get back in the repo")

like image 350
nonopolarity Avatar asked Mar 22 '11 01:03

nonopolarity


People also ask

How do I revert a file in Mercurial?

To revert a file to a specific changeset, use hg revert -r CHANGESET FILENAME . This will revert the file without committing it.

What does hg revert do?

hg revert changes the file content only and leaves the working copy parent revision alone. You typically use hg revert when you decide that you don't want to keep the uncommited changes you've made to a file in your working copy.

How do you dispose of local changes in Mercurial?

Reverting Local Changes If you use the TortoiseHg client to work with Mercurial from TestComplete, you can cancel all local changes not committed to the repository yet: Select File > Source Control > Revert from the TestComplete main menu.


1 Answers

Putting things on hold can be done in several ways in Mercurial. The simplest way is to simply not push it anywhere. After you go back in history with

$ hg update 3200

you can use

$ hg push -r .

to push only up to revision 3200. The . is important — it means the working copy parent revision, which in this case is 3200. Revision 3200 wont be "tip" in your local repository since you still have revisions 3201–3206, and the highest numbered revision is always what we call "tip". In other words, the history looks like this:

[3199] -- [3200] -- [3201] ... [3205] -- [3206]
             ^                              ^
            "."                           "tip"

where I've marked the current working copy parent revision and the tip revision.

When you start working based on revision 3200, the graph will change into

[3199] -- [3200] -- [3201] ... [3205] -- [3206]
                \
                 \-------------------------------- [3207]
                                                      ^
                                                  ".", "tip"

Please try not to add too much emphasis on "tip". It changes all the time and is generally not very interesting. If you jump back to 3206 and make a commit, then tip will denote the newly created revision 3208 in your repository. In another repository, tip can be something else, depending on what was pulled from you and when it was pulled.

If you often need to do hg push -r ., then I suggest you create an alias for it. Such an alias would be a gentler push and could therefore be called "nudge":

[alias]
nudge = push -r .

With that in your toolbox, you can always do

$ hg nudge

to send the changesets you've just created up to the server, without worrying about sending up any other branches that you might have put on hold.

Finally, remember that you can use

$ hg update 3206
$ hg commit --close-branch -m "Abandoning this line of development"

to mark the 3206 changeset as "closed". This means that it wont show up in hg heads and it wont be considered for merging when you run hg merge. You will need to use hg push --force if you push it to the server, but and is okay since you're not creating multiple open heads, you just add another closed head.

The trouble with multiple open heads is really that a new hg clone might update to one of them and that would be confusing — people wouldn't know where to start working. With recent versions of Mercurial, hg clone won't update to closed heads so you avoid this problem.

You can re-open a closed head by simply making a child commit based on it. This means that you can close a line of development temporarily with no ill effects, other than a note in the graph saying that the branch was closed at some point.

like image 150
Martin Geisler Avatar answered Sep 30 '22 02:09

Martin Geisler