So those are the four different ways to organize the same entities. Every commit is effectively a branch, any commit can have multiple parents and multiple children. 1 and 4 looked completely ridiculous to me, named branches seem to be heavyweight It's not always intuitive, but there is a good guide at the link above and as you get used to it, you end up clicking away with confident abandon.Īpparently there are 4 ways to handle branching in mercurial. When using TortoiseHG, use the Workbench rather than the other tools. Revision numbers are just a handy and more memorable shortcut when working with a single repo. Check out Hg Init for a good explanation. Revision numbers are inconsistent across repositiories. The hash codes are the important identifiers that will pass from repo to repo. They are a matter of convenience, no more. As I've added a couple of my own commits, all commits pulled after that have different revision numbers from the main central repo.ĭo not worry about revision numbers. Mercurial has not only hashes, but also revision numbers. Revising history is considered a bad thing in the Mercurial world, so the vanilla product doesn't always have everything that a Git user thinks it should have, but there are plenty of plugins for those who want to use the application but have different priorities. If you need one to perform a specific task, get it and use it. Some of them are very powerful tools and often they later get pulled into the core product. Do not be afraid of those additional plugins. This is a mistake I made with Mercurial when I was new to it. The "Using clone" option should satisfy your requirements. Mercurial have a whole page on their wiki describing different ways of " Pruning Dead Branches". I don't see why you'd consider it heavy-weight. They were designed for this exact purpose, where bookmarks weren't. If I were to use a branch then I'd rather use named branches. Just clone their repository and work in it, then make a pull request. Personally, for your scenario, I wouldn't bother even creating a branch, unless I was working on multiple changes, each of which would need to be accepted by the core developers. Or how am i supposed to work with my branches? What am I doing wrong? Is this normal and expected and should I just ignore these issues? I do hg update after pulling to move my master bookmark to the latest commit automatically, but I couldn't find a way to do that in TortoiseHG. As I've added a couple of my own commits, all commits pulled after that have different revision numbers from the main central And if I understand correctly, you can't delete commits in hg without additional plugins. TortoiseHG and hg log still show that commit and default branch has 2 heads. OK, in git I would just force-delete my branch and forget about it, so I delete my bookmark and now I have following problems: Now, my patch gets rejected and I want to remove one of my bookmark-branches from my repository. Apparently there are 4 ways to handle branching in mercurial.ġ and 4 looked completely ridiculous to me, named branches seem to be heavyweight and I feel that I'm not supposed to use them for quick 1-commit fixes, so I used bookmarks. So, I've made a couple of small patches and I wanted to track them as commits in my local mercurial repository. I've always used git before, but I want to contribute to python so now I have to learn mercurial and I find it very frustrating.
0 Comments
Leave a Reply. |