4 ms·

That's what was done. https://github.com/infusion/PHP/commit/790d551ac9ef8e204b44f4030291536137b0be25 https://github.com/infusion/PHP/commit/790d551ac9ef8e204b

• sc68cal 15y ago
  Why oh why didn't he fork php/php-src, make a branch for his changes, then commit as he went along? This just ends up as a big patchbomb. They're never going to merge his changes, and I don't blame them. EDIT - Hopefully we can straighten this around: https://github.com/infusion/PHP/commit/790d551ac9ef8e204b44f4030291536137b0be25#commitcomment-425333 https://github.com/infusion/PHP/commit/790d551ac9ef8e204b44f...
  • jrockway 15y ago
    In this case, it would be better to maintain it as several topic branches (so that each logical change can be implemented in as many patches as necessary), and then a good old octopus merge as "master" that you force-update every so often. (Yes, everyone hates you for modifying published history, it's evil, it will give you bad breath, yeah yeah yeah. But you have to think of this use case as a "code wiki" rather than "list of changes leading to the current state". After the patches are accepted, then don't force update them. When they are still in flux, modify history as often as necessary to make your changes easily comprehensible.)
    • mattyb 15y ago
      What do you mean by force update?
      • josegonzalez 15y ago
        master would always contain the php-base+the octopus merge. So if the php-base was 5.3.6, it would be 5.3.6+patches. Tomorrow PHP 5.3.7 comes out, and then master would be 5.3.7+patches.
    • sc68cal 15y ago
      His work is based off 5.3.x, there is probably a branch for it in the official SVN repo. As one commenter noted, the github mirror is stale so he'd need to fork it and then update it with the official svn to find the branch. It may make sense to rebase it off of trunk of svn.
• josegonzalez 15y ago
  No it wasn't. As sc68cal says, its a patchbomb. And if you think otherwise, let me know how I can revert his changes to remove short tags and the mysql* changes using a single git command (hint, there isn't). I'm all for changes to an open source project - whether it acts like one or not - but every open source developer should, at some point, learn that gigantic patchsets with lots of unrelated changes are a big no-no.
  • sc68cal 15y ago
    I'm just pissed that he didn't even bother to actually fork the project. On Github! WOW! All the previous commits before the fork? Gone. Poof. It's completely without any context. Even though there's a big "FORK" button!
    • mattyb 15y ago
      Well what project would he fork? The (apparently) official PHP mirror is way out of date: https://github.com/php/php-src https://github.com/php/php-src
      • sc68cal 15y ago
        Well, then just use git svn to update the master of his fork to match the official PHP svn. It'll just be a fast forward anyway. Two birds with one stone.
    • josegonzalez 15y ago
      This doesn't concern me as much, so long as he has a note saying "compiled onto commit hash blah". Cherry-picking would be a pain, but doable at that point.
    • xarg 15y ago
      I work on it. I currently update the git repo with the svn sources. This is somewhat slow... May I ask what you want to do with the dissected patches? Try to build a "clean" version as pbiggar has said?
  • 15y ago