GSoC: hg and git interoperability (status report)

Matt Mackall mpm at selenic.com
Tue Jun 23 18:52:47 CDT 2009


On Tue, 2009-06-23 at 17:56 -0500, Augie Fackler wrote:
> On Jun 23, 2009, at 5:50 PM, Matt Mackall wrote:
> 
> > On Tue, 2009-06-23 at 22:45 +0100, Abderrahim Kitouni wrote:
> >> Hi all,
> >>
> >> Another week, another status update.
> >>
> >> Today I finished most of the refactoring I intended to do.
> >> Now, I think it feels intuitive to someone who knows hg well, and  
> >> has already
> >> tried git. I'll try to explain here what it does (I'll update the  
> >> doc later),
> >> any suggestion on how to make it better are welcome.
> >>
> >> When cloning/pulling, one gets a bookmark for each branch in the git
> >> repository and, if the remote repository is in the paths section of  
> >> hgrc, a
> >> local tag <remote_name>/<branch> (Q: should this be configurable?  
> >> should
> >> 'default' be replaced by 'origin' in these tags to feel more like  
> >> git?)
> >
> > Wouldn't a bookmark be better here too?
> 
> My feeling was no, because the remote refs shouldn't be easily movable  
> (mostly because git would complain if you tried to commit to them).  
> I'm open to persuasion on that front though. The problem with  
> bookmarks is that they move when a commit happens.
> 
> It's the difference between origin/master and master in git  
> terminology - you normally commit to master and then push to origin,  
> which moves origin/master to point to the same as your master.

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.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial-devel mailing list