Hacker News new | ask | show | jobs
by xeromal 654 days ago
I wonder how the interim process is handled? They're accepting mailing list updates until the end of the year.

Does someone take the mailing list updates and manually PR them into Github? I've never actually used a mailing list so I'm curious how it works.

5 comments

With a mailing list you download a patch and apply it with "git am", then push it to the repository -- as you are presumably the maintainer who has permission to do that, and assuming the patch is good. You basically just do code review through email and reading the patches with some git functions. It completely sucks in my opinion, but some people like it, or it's how they do things in those parts, etc. When in Rome...

Having done a similar rodeo in the past -- migrating a project to an actual code review tool that enforces some more rigid structure, over plain patch files -- the interim process will probably be something like:

- Previously, some key people were allowed to commit to trunk directly.

- They would read emails/patches, do code review, apply, and push them to trunk.

- For now, you can keep emailing people your patches like you did before. Nothing will change.

- But at a certain point, you'll have to use this new Other Method.

- So, you should probably get familiar with Other Method early, by using it in the meantime, so you can be ready.

- At some point, no more patch files will be accepted and you will have to use Other Method.

- In the meantime, the maintainers will do double-duty and handle both venues.

Most projects are small enough where the double-duty isn't so bad. Most people will switch quick enough and you probably aren't dealing with 1,000 patches. It sucks but the payoff is considered worth it.

Eventually once this is completed you can do things like stop pushing directly to trunk and handling all patches to main through the Other Method. But you don't have to do that. It does sound like they'll stop accepting email patches, though.

Around 15 or so years ago, when a lot of projects were moving from cvs/mailing lists to git, there were a plethora of perl scripts and other tools which automatically took the code and sent the commit to git, usually taking a "rules" file as input which stipulated how to match various email headers with git tags etc. No idea how many of them are still around or used, but there should be some
No, git is an email driven program, not a terrible-webapp driven program. You pipe the email into git am (if it's from mercurial insert hg-patch-to-git-patch into the pipeline, which iirc just rewrites date formats mainly?)
Probably the same as with Mercurial before. Mailing lists are just regular emails that are automatically remailed to multiple recipients.
Remember Linus created git to help deal with an ever escalating inbox full of patches.
You have your history wrong here.
No I don’t. You’re confusing motivation with requirements. I’m talking about requirements.

But of advice. Outside of TV programming, when an American is talking about why a tool was created, they almost always mean its purpose, not its origin story. That inspiration story on TV is aimed at inventors. The people who use the tools don’t care, and it’s an anecdote for the rest of us.

I suspect that has something to do with that illusion we maintained of American Ingenuity. I don’t need the back story, what’s it for?

> But of advice. Outside of TV programming, when an American is talking about why a tool was created, they almost always mean its purpose, not its origin story.

It's so bizarre you're giving advice here based on such strong assumptions. There was absolutely no need to bring nationality into this discussion at all.

> You’re confusing motivation with requirements. I’m talking about requirements.

Or, they just disagree with your statement. It would have been better they say why though.

I'm sorry people are being dismissively snide and downvotive about this reasonable characterization of things (see: https://marc.info/?l=linux-kernel&m=111288700902396) because they think knowing the factoid that linux used bitkeeper is some kind of "epic own".
cough BitKeeper cough