4 ms·

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 m

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.

hinkley 2y ago
Remember Linus created git to help deal with an ever escalating inbox full of patches.
- layer8 2y ago
  You have your history wrong here.
  - hinkley 2y ago
    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?
    - jraph 2y ago
      > 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.
    - ruthmarx 2y ago
      > 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.
- aryonoco 2y ago
  cough BitKeeper cough
  - hinkley 2y ago
    [flagged]
    - lillecarl 2y ago
      https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git https://git-scm.com/book/en/v2/Getting-Started-A-Short-Histo... A lot
      - hinkley 2y ago
        No, that’s why git was started. I know why git was started. What does it have to do with how git was designed?
        jraph 2y ago
        That's why and how. > This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. (Emphasis mine). Git was designed with the experience of using BitKeeper in mind.
- juped 2y ago
  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 https://marc.info/?l=linux-kernel&m=111288700902396) because they think knowing the factoid that linux used bitkeeper is some kind of "epic own".
  - hinkley 2y ago
    [flagged]
layer8 2y ago
Probably the same as with Mercurial before. Mailing lists are just regular emails that are automatically remailed to multiple recipients.
juped 2y ago
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?)
aryonoco 2y ago
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
aseipp 2y ago
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.

hinkley 2y ago

Remember Linus created git to help deal with an ever escalating inbox full of patches.

layer8 2y ago
You have your history wrong here.
- hinkley 2y ago
  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?
  - jraph 2y ago
    > 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.
  - ruthmarx 2y ago
    > 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.
aryonoco 2y ago
cough BitKeeper cough
- hinkley 2y ago
  [flagged]
  - lillecarl 2y ago
    https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git https://git-scm.com/book/en/v2/Getting-Started-A-Short-Histo... A lot
    - hinkley 2y ago
      No, that’s why git was started. I know why git was started. What does it have to do with how git was designed?
      - jraph 2y ago
        That's why and how. > This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. (Emphasis mine). Git was designed with the experience of using BitKeeper in mind.
juped 2y ago
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 https://marc.info/?l=linux-kernel&m=111288700902396) because they think knowing the factoid that linux used bitkeeper is some kind of "epic own".
- hinkley 2y ago
  [flagged]

layer8 2y ago

Probably the same as with Mercurial before. Mailing lists are just regular emails that are automatically remailed to multiple recipients.

juped 2y ago

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?)

aryonoco 2y ago

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

aseipp 2y ago

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.