> and the choice of various algorithms such as “patience.”
Again, possible with git
> Finally, there’s nothing to stop the mailing list style of collaboration from adapting to emerging diff formats, such as structural diffs
I don't think Git/Github developers will sit idle when improved collaboration methods are discovered
> The bulk of communication around a new feature is in its proposal, not around the subsequent code
This can be done by opening issues or by simply using a Google doc. Mailing lists are not a very good solution to this. There is a lot of extraneous garbage that needs to be parsed before getting to the meaty stuff
etc etc.
Most of author's complaints seems to not be entirely accurate
> Challenges for mailing lists
One big challenge is also how good Github is, the UX is well done. Almost every time I wanted to do something there is button right there to do it. Also, it is very fast. Projects like PJAX[1] has meant that Github is miles ahead of competition. I have used Github, Gerrit etc and I have to say, once you started using Github, there is no going back
[1] https://github.com/defunkt/jquery-pjax
When a Github user clicks on a link, it is converted to an XHR request and then only the part of the page that needs to change are fetched. The page is updated and browser history is manipulated using PushState to not break the back button !
You can view them if you go to the commit on which the comment was made.
>Furthermore, patches from multiple authors can’t mix in a Github pull request. The person opening the pull request “owns” it.
Actually, no. Pull requests are for reveiwing one branch. If that branch is accessible to multiple authors they can be collaborate on that branch
> annotating the hunk headers with which C functions are affected
Seems like you can do this with git as well : https://stackoverflow.com/a/16528858/3528640
> and the choice of various algorithms such as “patience.”
Again, possible with git
> Finally, there’s nothing to stop the mailing list style of collaboration from adapting to emerging diff formats, such as structural diffs
I don't think Git/Github developers will sit idle when improved collaboration methods are discovered
> The bulk of communication around a new feature is in its proposal, not around the subsequent code
This can be done by opening issues or by simply using a Google doc. Mailing lists are not a very good solution to this. There is a lot of extraneous garbage that needs to be parsed before getting to the meaty stuff
etc etc.
Most of author's complaints seems to not be entirely accurate
> Challenges for mailing lists
One big challenge is also how good Github is, the UX is well done. Almost every time I wanted to do something there is button right there to do it. Also, it is very fast. Projects like PJAX[1] has meant that Github is miles ahead of competition. I have used Github, Gerrit etc and I have to say, once you started using Github, there is no going back
[1] https://github.com/defunkt/jquery-pjax When a Github user clicks on a link, it is converted to an XHR request and then only the part of the page that needs to change are fetched. The page is updated and browser history is manipulated using PushState to not break the back button !