What is the meaning of the TortoiseHg Workbench Graph symbols?
I googled it and got only this (http://tortoisehg.bitbucket.io/manual/2.0/workbench.html) but it has no description of the symbols. For example:
Pentagon (that sometimes changes color)
dashed branches
Circle: public phase
Pentagon: draft phase
Square: secret phase
Bar: close branch
Dash: graft
There is also the "diamond" shape. It means it's a patch.
Related
What does 'ignore' mean in the perforce revision graph for a file?
I can see a lightly dotted line, the legend says 'ignore' and the action on the file is 'integrate', but what does this mean?
It records the fact that, when that revision was submitted, you instructed Perforce to "accept yours".
This is very useful because it tells Perforce that the reason that a certain change is in one branch, but not another, is because you explicitly specified that.
In future integrations, Perforce knows not to present that change again, so subsequent merges are cleaner and simpler.
For an example of where this is useful, see: Proper way to ignore source files during Perforce integration
The Mercurial help text says, that the "strip command removes the specified changesets and all their descendants." This sounds very much like rewriting history to me, and that it must cause problems if somebody has based his work on one of the changesets that suddenly is removed. But the help text also says that the command "is not a history-rewriting operation and can be used on changesets in the public phase." I am sure that the person who wrote the help text knew very well what he was doing, so what am I missing to understand this?
The key point is that if you strip a public changeset, and then pull it again from somewhere, you haven't caused any issues. You just get the original changeset back.
If you (for example) collapse two public changesets together, and then pull the original from somewhere, you now have two branches. One with the original two changesets, and one with the collapsed changeset, but both have the same changes. At that point hell breaks loose and child eating monsters roam the earth.
Hence 'history re-writing' isn't the same as 'history stripping'.
davidmc24 pointed out this post by Matt Mackall (Mercurial's father) in which he says basically the same thing
I can't say it with certainty, but my guess is that it's "grandfathered in". hg strip started out as part of mq which predates the addition of phases by at least three years.
Likely better phrasing would be:
is not *considered *a history-rewriting operation and can be used on changesets in the public phase
When phases were added a huge amount of care was taken to break no one's existing workflow. Commits start out in the draft phase and become public once pushed. Any phase-aware commands knows that after pushing the commit's phase is public and not to allow modification if it (unless the push was to a non-publishing repository...).
However, there were people already using strip manually and in scripts to remove changesets that had been pushed, and if strip had after an upgrade suddenly said "Hey, you can't strip that it's public!" then those people would have had their backward-compatibility promise broken.
Phases is slowly growing into a pretty amazing evolve system that will be a much better choice than mq for almost all cases, but I still doubt we'll ever get Matt to remove mq and strip -- he still insists on maintaining a Python 2.4 compatible codebase and that's 9 years old!
Tl;Dr: Even though strip was always a disabled extension, too many people use it to change it's behavior w/ the advent of phases.
I have run into an interesting situation that I do not know how to describe. So I here is a screenshot of it (note that two programmers are working here with a central repository that both synchronize with):
The image on the left is updated to the other programmer's core (which is now the head) and the image on the right is updated to my core before the merge to dev.
As you can see, I have one Core branch #372 merging into Dev. The other programmer forgot to merge with my changes at #372 (which I had already pushed to the central repository before this changes from 375 and onwards) and continued on.
So now I have a core branch that merged into dev, and is sort of left headless. The other programmer's core is now going to be the one I am going to start with. That is not an issue. What is an issue is seeing two cores and the messy tree with confusing branching.
What can I do to end up with one core branch only? Or is this ok to have?
As you can see, I have one Core branch #372 merging into Dev. The other programmer forgot to merge with my changes at #372 (which I had already pushed to the central repository before this changes from 375 and onwards) and continued on.
That's not what I see. #372 is a parent of #373 on both sides. Both graphs, if you remove #381+ and #372+, are the same. They've been drawn differently just because the parent of the current working copy is different.
Granted, it looks a little odd, but there's no issue here. After #372+ is committed, it will need to be merged with #381 (or whatever the current Core head is by then) at some point, but that's nothing exceptional.
Right now, Core actually has 0 topological heads since changesets 381 and 372 were both merged with dev. On your graph you see that long line extending from changeset 372 because your working directory is on that changeset right now. The line is indicating that any commits you make will be children of 372. The other programmer's working directory is on changeset 381, which is why his graph looks different. Once you update to 381 your graph will look the same as the other one.
So to answer your question, this won't be an issue since Core's branch heads have all been merged into dev. Also if you did end up with multiple topological heads on Core, mercurial would warn you about it when you pulled in the new head.
I'm maintainig a project with two heads which are pretty much alike so i thought it would be possible to just transplant a changeset from one branch to the other.
But this sometimes fails because the code to change is on a different line and i end up with .rej file.
What are my options from that point on now?
Ist there any visual interface that can help me fix this - like when resolving a merge?
Can i tell transplant to ignore line numbers?
Mercurial 2.0 introduced the Graft command.
Like explained in the following SO answer : Graft vs. Transplant, Graft uses the internal three way merge mechanism instead of the patch one, so it is able to better handle the kind of problems you're describing. You can also have a look on this question : mercurial: how to cherry pick during merging.
I downloaded TortoiseHg 1.0 for evaluation. For the life of me I can't figure out how to make a branch. It seems to understand branches (e.g. in its repository browser) but I just can't seem to find a way to make a branch. This seems like such a fundamental capability since out of the often touted benefits of DVC is the lightweight branching.
I Googled around and couldn't find much discussion of this topic (at least for recent versions) so I have to assume I'm missing something, right?
Update: So I flagged Chad Birch's answer below to answer the "new branch" issue. As he correctly points out, you do a commit and then click on the branch button to bring up the branch maintenance dialog which is where you create new branches. I kind of wish they had given us a context menu option for this. Once you've branched, the next natural question is how to merge and this is also not obvious. It turns out that option is buried in the repository explorer. You need to select the head of another branch, right-click and then select "Merge with...".
As shown in the docs, all you should need to do is just click on the branch: default button near the top of the commit dialog, and change to a new branch name.
To start new branch with TortoiseHg press Commit... then, above Commit message press Branch, then "Open new named branch: "
Just wanted to add that in order to push new branch to remote repository there is a checkbox on the Synchronize tab under Options of "Allow push of a new branch" - you have to remember to turn it off again right afterwards.
Most of the time in mercurial, you clone the repository to make a branch.
You can then merge the separate repositories once you made your edits and commits.
This might sound like it would take up a lot of disk space but on most operating systems, mercurial will make hardlinks instead of copying the files. Anyway, disk space is normally cheap, and because it's local it's rather fast.
If you think about it, every "checkout" (in svn terminology) or "clone" (in mercurial terminology) is really a branch that will probably be merged back so it makes lots of sense that clones are the common way of making branches.
Before commiting, click on Branch button (see image), Then select a branch or create a new one (by typing where you select the branches).
See the image here