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.

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

Reply via email to