This question already has an answer here:
How to push just one specific patch in Mercurial Queues?
(1 answer)
Closed 6 years ago.
I have two patches:
patch1
patch2
When I apply patch1, that is the only thing that gets applied. When I do hg qpop and then do hg qpush patch2, for some reason patch1 gets applied too. How can I make them independent from each other?
You need to use the --move option for that. For example:
hg qpush --move patch2
This will apply only patch2, but not any patches on top of it.
Related
This question already has answers here:
Mercurial Remove History
(2 answers)
Closed 2 years ago.
I want to ask a question about Hg.
You can see the picture that there is a branch from 196 to 199, and now I want to remove the branch in the server version and use the 195 as the newest version, could you please tell me how to do that?
Thank you so much!
If 196:199 was already pushed to remote, you can't delete this branch (check hg out or phases of these revisions)
If 196:199 are pure local, you can just simply hg strip not needed anymore anonymous branch
Anyway, you can:
Dummy merge r199 into r195 and continue work
Forget about branch, and continue your work from 195 (first push with new child-commit of 195 will require -f due to new head in branch)
This question already has answers here:
How to change the default branch to push in mercurial?
(3 answers)
Closed 6 years ago.
I would like to configure Mercurial to push the commits on the current branch only, instead of all draft commits - much like Git does when the push.default is set to simple. I scanned the hgrc manual page, but couldn't locate the option which enforces this. How is it called?
Although deprecated, you can set defaults for commands in hgrc:
[defaults]
push = -r .
The recommended alternative is aliases:
[alias]
pushcurrent = push -r .
How do I list all unmerged branches?
That is, I want a list of all branches that are not closed, and their head is not merged into some other branch.
You can use the branches command
hg branches --active
Branches are considered active if their last commit has not been merged into another branch. Closed branches won't appear in the output at all.
If you need to handle the list programmatically, and can use .NET, there is also a Mercurial .NET library that can make this easy.
According to http://bugs.python.org/issue15917 this should work:
hg log -r "head()-parents(merge())-closed()-tag(tip)" --template "{branch}\n"
The corresponding TortoiseHg filter is
head() and not closed() and not parents(merge()) and not tag(tip)
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Generating a list of which files changed between hg versions
hg diff -r 5 -r 10 will give the differences between revisions 5 and 10. But I want to see specifically just a list of files that are different - I don't want to see the full diffs. Is there a quick way to do this?
hg status can do this.
The main purpose of hg status is showing modified files in the working directory (in comparison to the last commit).
But you can use the --rev parameter to let it compare two specific revisions instead, like this:
hg status --rev 5 --rev 10
I love the flexibility of named branches but I have some concerns about the prolifieration of heads.
Even when the branch is closed, it still shows up in the heads. I have an idea for how to clean up the output from "hg heads"
My question to the gurus: "What am I missing?"
First off you may ask, Why might I want to totally hide the head of a named branch? For various reasons:
the feature is a bad idea
the feature is a good idea that is not ready for merging to tip, but maybe in a few months
the branch is a patch release to an older tagged version
edit: It turns out the prolifiration of heads is a symptom of the older version of mercurial I was using. Closing the branch hides the head of the branch it on newer Mercurial versions.
My idea is to have a "dead" head branch onto which all these closed branch heads will be merged.
The dead head would be parented by changeset 0 and serve the sole purpose of bundling up the stray heads that are not needed right now.
The deadhead has only other deadhead children, which never get merged back into the default branch.
You can use hg commit --close-branch to mark a branch as closed:
http://www.selenic.com/mercurial/hg.1.html#commit
Closed branches will not show up in hg branches or hg heads by default (only if the -c/--closed option is specified), so I'm not sure how you're seeing "clutter"?
What exactly would you gain by merging things?
There seems to be a downside to leaving dead heads which is not solved by later versions of Mercurial.
Suppose you have a lot of closed branch heads and only a single non-closed active branch. Suppose further that at some later point you make a bad commit (rev bad) on top of the non-closed head (rev good). Before you push you'd like to clone your repository dropping that bad commit. That is usually a simple thing to do -
hg clone --rev good BadRepo FixedRepo
This unfortunately does not pull the closed branch heads since they are not ancestors of rev good. All those branches which were closed will not be closed in the cloned repository. I tested this with Mercurial 2.3.1.
Thoughts?
p.s. The hgflow extension does close feature and release branches before merging. This avoids the closed heads problem.
Regarding the clone being an ugly approach, it has worked quite well and easily for me. The clone replaces the repository with the bad commit. The clone is a local effort. That bad repository is just discarded. I usually realize I've made a bad commit very soon after.
The -b option is just a way to rephrase the --rev by using a branch name instead of a change set identifier. Using the --rev option does pull the entire topological tree under the revision. If the revision is the head of the branch then the --rev clone is the same as the -b clone. -b leaves the same problem that I described with the --rev option. Branches which were closed in the original repository get reopened if they were left as heads.
If the pattern is to leave closed heads then they will soon greatly outnumber relevant heads. Getting those closures into a clone is quite an effort unless you do a full clone.
I feel I've muddied the waters with why I might do a partial clone. I'll restate my concern about closure heads more carefully.
For any partial clone from repository X to repository Y, if there exists a branch B in repository X with a closure head and that branch is included in the clone for purely topological reasons, then branch B will not be closed in repository Y. Further if the merging pattern is to generally leave closure heads then the number of closure heads is of order development time.
This is a concern to me so I close my branches before I merge. I use hgflow (http://nvie.com/posts/a-successful-git-branching-model). A possible partial clone would be to clone the development branch and follow that with a pull of the master branch (e.g. if you wish to eliminate dead ends). If feature and release branches had been closed after their final merges then those branches would be reopened in the clone.