On Mon, Dec 30, 2013 at 08:41:13AM +0100, Antoine Pelisse wrote: > On Sun, Dec 29, 2013 at 11:24 PM, Mike Hommey <m...@glandium.org> wrote: > > On Sun, Dec 29, 2013 at 12:30:02PM +0100, Antoine Pelisse wrote: > >> Mercurial can have bookmarks pointing to "nullid" (the empty root > >> revision), while Git can not have references to it. > >> When cloning or fetching from a Mercurial repository that has such a > >> bookmark, the import will fail because git-remote-hg will not be able to > >> create the corresponding reference. > >> > >> Warn the user about the invalid reference, and continue the import, > >> instead of stopping right away. > > > > It's not invalid, it's used to indicate deleted bookmarks. (Tags have > > the same property) > > Hey Mike, > Indeed, I don't know how I ended-up with such a bookmark, but it > prevented me from git-cloning the repository (and the backtrace was > not very helpful at first). > But I'm still not sure what you mean by "deleted bookmarks" ? > I guess it's not "hg bookmark --delete", as it would not be listed at > all. Is it "hg strip some_changeset" that end-up deleting the > bookmarked changeset ? I think I've tested this use-case and it moved > the bookmark to a parent changeset.
Mmmm after looking at the mercurial code, it looks like i was wrong and bookmarks are not handled like tags. You can actually create such a bookmark on purpose with: $ hg bookmark -r null foo Then, if you do, say: $ hg up -r foo $ echo a > a $ hg add a $ hg commit -m a Then you end up with a completely new head with no ancestors in common with the others. In git terms, $ hg bookmark -r null foo $ hg up -r foo is equivalent to $ git checkout --orphan foo But git never creates an actual ref in that case. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
