GSoC: hg and git interoperability (status report)

[Giorgos Keramidas]

On Tue, 23 Jun 2009 19:18:19 -0500, Augie Fackler <durin42 at gmail.com> wrote:
>On Jun 23, 2009, at 7:12 PM, Giorgos Keramidas wrote:
>> On Tue, 23 Jun 2009 18:52:47 -0500, Matt Mackall <mpm at selenic.com> wrote:
>>> I'm fairly clueless about both git and bookmarks, but my
>>> understanding of the latter is that if you have two bookmarks
>>> pointing to parent, either zero or one of them will be bumped when
>>> you commit, but never both.
>>
>> Yes, that's a reasonably accurate description of how bookmarks work
>> when [bookmarks] track.current = True.
>
> My concern is that it's relatively easy to move a bookmark accidentally
> without realizing it, whereas the refs from remotes (in  git speak)
> should be more-or-less immutable as far as I can tell.

That's a valid concern.

There are a few gotchas that one should be careful about.  One of them
is that they can 'shadow' other names like 'tip'.  I recently mistyped:

    hg mark -f -r NAME tip

and ended up with a new bookmark called 'tip'.  You can imagine the
quite amusing WTF moments when I tried looking at history and saw two
different 'tip' changes.

The bookmarks extension is a *very* useful extension.  I use it every
day now.  The catch is that its most important feature -- that bookmark
names can slide forward or backward pretty much arbitrarily and/or
shadow other tags or special revision names -- is also a bit 'dangerous'
when used carelessly.

On the other hand, the sliding tag feature maps very well to the fast
forward merges of git branches, so if it simplifies the implementation
of git-hg interoperability that would be nice :-)