PyPy has moved to Git, GitHub | PyPy

[utterances-bot]

PyPy has moved to Git, GitHub | PyPy

https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html

[mattip]

On reddit someone commented:

---

That process was likely a lot slower than it needed to be. You generally don't need to check out a git ref to operate on the ref itself, only if you actually really need to change your working tree.

Since the git notes add command works on the current HEAD, I needed to checkout each commit in turn and then add the note

git notes add works on the current HEAD.... by default. You can easily pass it an object id to avoid the checkout.

while read branch; do git checkout branches/$branch && git push origin branches/$branch; done < branches.txt

Same thing, you don't need to check out a ref to push it.

git push origin <branch>

You can even just push just a commit hash, just if you do you need to tell git to push it as a new head to the remote by explicitly stating the namespace:

git push origin <hash>:refs/heads/<branchname>

[amunizp]

Was gitlab considered? Could it be considered? Should be easier after the move to git.

[mattip]

We were on gitlab: foss.heptapod.net is a friendly fork of gitlab. The problem is the friction of interacting with other software packages when they all are located on github.

[arigo]

People who wish to continue to use Mercurial can use the same method below to push to GitHub.

I don't think this sentence alone will help people like me that are not very familiar with git. As far as I understand it, outside contributors on github must go through the process of making a clone on github, fetching a local copy, pushing some new commits in it, and using the github web interface to propose that as a pull request back to the main repo. Is there also very different approach starting with the mercurial copy of the repo somehow?

[mattip]

On 3/1/24 11:30, Armin Rigo wrote: People who wish to continue to use Mercurial can use the same method below to push to GitHub. I don't think this sentence alone will help people like me that are not very familiar with git. As far as I understand it, outside contributors on github must go through the process of making a clone on github, fetching a local copy, pushing some new commits in it, and using the github web interface to propose that as a pull request back to the main repo.

Yes, I think that is accurate. The path I detail in the blog post is to convert a hg repo to a git one, not to remain with mercurial. I phrased it in a misleading way, sorry.

Is there also very different approach starting with the mercurial copy of the repo somehow? —

There may be some way to use the github API to create a pull request from a patch file, but it is bound to be complicated. I would suggest that if people wish to avoid git, they submit patches to a github issue. You may be able to use the hg-git mercurial plugin [0] to keep up-to-date with the latest pypy HEADs. Maybe the heptapod people have other ideas. Matti [0] https://hg-git.github.io/

[arigo]

Thanks! So the best solution for me is probably just to check out the new pypy repo in the usual way with git and then submit patches as github issues, generated with the appropriate set of git diff options.

[mattip]

People who wish to continue to use Mercurial can use the same method below to push to GitHub.

Well, I may have misrepresented that. I meant "people who wish to convert their local Mercurial repo to Git". But truthfully it is probably easier to do git clone https://github.com/pypy/pypy than to convert the repo and get all the correct branches.

[glandium]

You should ask github to repack the pypy repo, because it's 2GB instead of the 200MB it could be after an aggressive repack or 400MB after a less aggressive repack. Presumably, you just pushed the result of git-remote-hg without a repack, and git-remote-hg isn't really great at creating tight packs.

[cfbolz]

@glandium: interesting suggestion! how would we do that? is that exposed in the UI or do you need to send an email to the right person?

[GreyXor]

Github an open source synonymous ? Guys, are you aware that GitHub itself isn't open source ? What a joke.

[mattip]

You should ask github to repack the pypy repo

Thanks @glandium. I reached out to github support and they did something, now the repo is much smaller.

[BugZappr]

It's sad that Hg is being abandoned in droves. I only use it for my personal SCM needs, but IMHO, here are things it still stands out on.

• Easier for newbies to learn/more intuitive. This means that EVERYBODY who uses git must have a steeper learning curve, and do things in a non-intuitive way. This leads to errors. I tried making a branch, and then trying to make it the head, and wound up with some weird result that I couldn't fix. Not a problem in Hg.
• No Windows native version of Git. If you want the whole thing, you must down a HUGE installation of MSYS2 on Windows. Not so with Hg.
• One supposed disadvantage of Hg I consider to be an advantage: when you fork a repository, it copies the whole project. Disks these days have plenty of room for this, on all but the largest projects; in which case, a bigger disk will do. In Git, if you have a tree with lots of branches, but they all depend on revision 1.0 (or 0.1, or whatever), and your HD goes bad and loses one of those sectors of that original version, if I'm not mistaken, there's no recovering it. There is enough info in a Hg branch to rebuild the branch, should a sector go bad in the trunk.

I can't say if the advantages of Git hold up under scrutiny for larger projects, e.g. in terms of performance. Hg is probably compiled in something like PyPy, so it should be comparable in terms of performance. Anyway, you can add these to lists of how Hg is better. I'm really glad QtCreator supports it, anyway.

[arigo]

@BugZappr some of us in the PyPy project agree with you. Personally, I just can't use git, I break it as soon as I try to go beyond the basics. Sadly, the world moved on, and nowadays being a git project is kinda expected for all serious open-source projects. Also, Github adds more and more conveniences whereas public Mercurial equivalents abandon their Mercurial support.

[mattip]

readthedocs.org, where we host our documentation, announced they will only support git, so it is a good thing we moved when we did. We could host our documentation from github pages instead, this also requires git.