Re: [PATCH v5 00/14] New remote-hg helper

On Sun, Nov 11, 2012 at 11:17 PM, Chris Webb [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

Implemented now. I'm not handling the 'tip' revision, but most likely
it's also the '.' revision. In this case a fake 'master' bookmark will
be created to track that revision.

Hi Felipe. Sorry for the slow response, I've been snowed under with work and
have only just got around to testing your latest version.

The new remote-hg.track-branches=false option is great and does exactly what
I was hoping for. For the benefit of the list archives, one natural way to
use it is

  git clone -c remote-hg.track-branches=false hg::foo

when cloning the relevant repositories, if you don't want the setting
globally for every hg-remote clone.

Cool :)

During testing, I've seen some strange behaviour which I think is caused by
using the . revision instead of tip:

$ hg init h
$ hg init h2
$ ( cd h && touch foo && hg add foo && hg commit -m foo && hg push ../h2 )
pushing to ../h2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
$ git clone hg::h g
Cloning into 'g'...
$ git clone hg::h2 g2
Cloning into 'g2'...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$

The reason for this is that by default . == null (not tip) in the repo h2
which we pushed into from h. The hg equivalent of a bare repo typically has a
null checkout like this. (Actually, the checkout of HEAD seems to break
whenever . is different from tip, not just when it's null as in this example.)

Well, I thought in those cases we didn't want HEAD to be updated.
People can still use the repo and checkout whatever branch they want.
But '.' is not  really the equivalent of HEAD. Since there's no
equivalent, I think it makes sense to try first '.', and then 'tip'.
This means that we would never have a HEAD pointing to nowhere.

I've added a patch for that.

Cheers.
-- 
Felipe Contreras