Git-remote-hg is another alternative CLI tool very similar to hg-git, but that allows you to pull/push to hg repositories from git. If you’ve done it correctly, your TortoiseHg should look like this: Once you’ve installed hg-git, set it up alongside the bookmarks, and you’re ready to go! It looks ugly, but there’s no other way if you want to fully preserve lossless information between git hg. Hg-git can preserve Mercurial’s branching information by writing extra metadata at the end of the commit.
Tortoisehg tag vs bookmark how to#
See Github and Bitbucket on how to setup an ssh key. You can only pull/push to remote respositories via ssh by writing and to local repositories. by accepting a pull request that contains them)Īnother thing: hg-git cannot use the https protocol. But if you want to keep using TortoiseHg with your git repo, then you shouldn’t allow octopus merges (i.e. Another source of problems is that git supports octopus merges (merging multiple commits into one) whereas hg only supports merging two commits into one at a time.īecause you’re going hg -> git route, octopus merges shouldn’t be a problem. Beware however, the plugin does not support LFS.
Tortoisehg tag vs bookmark update#
It’s the equivalent of a chat program asking its users to write an SQL query to update their nickname. This results in a horrible user experience. It exposes internal mechanisms (like reference counting and garbage collection) to the user. Hg bookmarks are just ‘tags’ that can be easily moved to point between commits and don’t alter the history of hg, thus they behave very much like git ‘branches’ do.ītw this is why I don’t like git. This is why conversion tools tend to ignore the branch metadata in hg, and use hg bookmarks instead. OK so now that we have explained how git works, it’s become clear that the concept of hg branches does not translate well to git’s branches at all. The remote’s commit must be tagged because otherwise it would have no reference count and thus could not show up in the timeline.
With the animation it should become clear that: This means that in git, it is possible for a commit to belong to multiple branches (because it has multiple children, each belonging to different branches)īecause git branches are just like ‘tags’ that can be easily switched around, this means that an entire history of commits can disappear if the branch tag is moved somewhere else.Ī picture is a thousand words, and this GIF is 4000 words, what happens when you move the branch tag to a different commit: In git it is the leaf commit which decides what a branch is until the root(s) are reached, while in hg it is the root commit(s) which decide what a branch is.
When you create a new commit, the branch tag is moved from pointing to its current commit to now pointing at the newly created commit so that your new one has a non-zero ref count, and all of its parents are kept alive. You can still access them via ‘git log -g’ as long as the garbage collector hasn’t been run.Ī git ‘branch’ is a reference to a commit that increases its reference count, and this forces all of its parents to stay alive. If a commit has a reference count of 0, it gets garbage collected and disappears from the official timeline. Branches are more like pointer references that reference-count the commits. Git has a leaf-to-root approach to branches. Technically speaking hg can have more than one root per branch, but this is discouraged. All of its children belong to that branch unless they explicitly open a new branch or are merged into an existing one. Mercurial has a root-to-leaf approach to branches: a commit creates a branch and becomes the root of that branch. The second main difference, and linked to this mutability, is how both treat branches. Git on the other hand is completely mutable and history can change. And doing so can cause issues as replicating those history edits can be painful. Only advanced operations (which must be explicitly enabled) can manipulate history. The first main difference is that hg treats the repo history as immutable. If you’re a git expert, you can skip this section. We need to explain a few differences from hg to git. This entry was posted in Ogre and tagged hg-git mercurial migrating from Bitbucket to Github on Septemby Matiasīecause Ogre uses Mercurial hosted on Bitbucket, and Mercurial is being removed, this guide is aimed to helping our users to migrate as painless as possible.
0 kommentar(er)
