only want heads and tags

[schacon]

i didn't test this, since i don't have a test env setup, but something like this will fix stuff like #219 #217

we should only be wanting and converting refs in the heads/ and tags/ spaces, since that's all we deal with after the fact. anything else will just show up as weird unreferenced heads.

[marutosi]

This pull request works fine for me.

$ hg clone -U --config extensions.git=`pwd`/hg-git/hggit git://github.com/chiliproject/chiliproject.git
$ hg bookmarks
   master                    4810:7ee3c0518289
   stable                    4785:e74c0ec76076
   unstable                  4789:52d4b3210b0a

$ hg log -r 'head() and not bookmark()' --template '{node|short}\n' | wc -l
0

After editing .hg/hgrc

$ hg tags
tip                             4810:7ee3c0518289
default/master                  4810:7ee3c0518289
default/unstable                4789:52d4b3210b0a
v2.0.0                          4785:e74c0ec76076
default/stable                  4785:e74c0ec76076
v1.5.0                          4774:e5150675f48a
v2.0.0RC3                       4768:0a7317c97b65
v2.0.0RC2                       4744:517606f49db2
v2.0.0RC1                       4714:922460ee926e
v1.4.0                          4682:0d81ecde98b7
v1.3.0                          4373:087fb62cbd47
v1.2.0                          3905:fed17d3ef455
v1.1.0                          3847:feda465d209b
semver                          3847:feda465d209b

[mcclure]

I think that this is correct.

Here is what I did to test. I started with a copy of hg 1.8.4 and hg-git rev 84bff2c (without this pull request). I cloned a new copy of the hg-git repository as repository A. Then I switched hg-git to rev 8d0df75 (this pull request) and I cloned a second new copy of the hg-git repository as repository B.

Here is a copy of hg heads followed by hg log on repository A: http://vote.grumpybumpers.com/j/g/repoa.txt Here is a copy of hg heads followed by hg log on repository B: http://vote.grumpybumpers.com/j/g/repob.txt

It looks like this change not only removes the "github merge button" commits, but also removes all of the "pull request" commits. Is this correct? Being able to see the entire "network" of github commits from a single clone was actually sort of a neat feature but, thinking about it I guess it is also unnecessary because if you actually want the entire network you can just pull in the different forks one by one. I tried cloning another github project (polycode) and pulling each of the different forks in one at a time with 8d0df75 and they all merged in properly, I got a consistent repository with no garbage commits and only the things that ought to be heads listed as heads. So that's fine.

I then tested with 1.9 and got the same apparently correct behavior.

Thanks!

[schacon]

Awesome - yeah, this should only be showing branch references since that's all we add bookmarks for, so removing the other pull requests across the network is not what it should do by default. Looks like there is a good workaround, so I think this is the better way to do it.

It's possible that you can currently say something like hg pull <repo> <heads>, and I'm not entirely sure what the python matching code here does, but it's possible that you can have hg pull in the pull request heads with some sort of pattern:

https://github.com/schacon/hg-git/blob/8d0df7595bb63c1ac0ef43258f083c48372378ec/hggit/git_handler.py#L773-785

Or, if not, that section of the code could probably be pretty easily modified to accept patterns so you could say hg pull <repo> pulls/* or something like that.

[mcclure]

Yeah thinking about it I see lots of problems with pull-the-whole-network as a default behavior. Your patch does it the right way.

[durin42]

Awesome. The close button discarded my comment, and javascript-heavy github means it's gone. My question was:

How would I have figured out that this was necessary? I looked in the underlying git repo (.hg/git) and didn't see extraneous refs hanging around, was I just looking in the wrong place?

Merged btw.

[schacon]

Sorry about the lost comment, that's an issue we've seen lately and is in our queue to fix.

As far as how would you know, it's hard to say - it's a pretty subtle bug. Because we're using Dulwich to do the actual fetch, the mechanisms for fetching objects and updating refs were slightly out of sync - the fetch was broader. This would have bitten us weirdly with stuff like Git notes, replacements and what not.

Thanks for merging - if I have a few minutes, I'll try to update this to accept patterns for the pull, like I was saying earlier. Being able to pull down the pull request heads easily would be pretty cool.