I mean, come on, somebody fixed it for you and when you as the maintainer complain about the quality of the fix then the FFF rule applies also!
I also have nothing against occasional little personal forks, but methinks that keeping track of the issues upon each update could be painful.
No. Because unlike the one contributing a "not good enough" fix, the maintainer now has to carry the burden of continued maintenance of that fix. If that fix makes that worse, declining is absolutely reasonable. Of course that's different for fixes with just a typo-level of complexity.
Of course it is! It's up to the maintainer to decide! It's their problem, like, literally! Of course, this should not be an invitation to blindly commit and push dumb fixes, even if they solve some problem. But generally:
> If that fix makes that worse
... then it's up to the maintainer to politely ask the contributor to make the fix better, or make it better themselves, or bugger off, meaning, then ...
> declining is absolutely reasonable.
I agree.
Open Source goes both ways: nobody forces you to use some rando's code off of github but also nobody forces said rando to to use some rando^2's patch for his own code
But I think it's harder to determine what has changed between multiple rebases. It rewrites history, as it's said. However, I hear the reflog keeps it somehow...
GitHub keeps track of this. If you go to your commits, your own merge commits of joke-polishing would show up alongside your own.
It's heartening though that an exchange between maintainer and contributor could be like that of a maintainer and future maintainer.