Hacker Newsnew | comments | show | ask | jobs | submit login

Still fundamentally broken, in that it doesn't provide an option to receive these as email attachments.

http://www.wired.com/wiredenterprise/2012/05/torvalds_github...

> Torvalds says he brought up his problems with GitHub’s creators, but “they didn’t think they mattered.”

This is the crux of the problem. GitHub spends a great deal of resources working on a mac app and a windows app, which aren't interesting to people who do things the UNIX way at all. Meanwhile support for a good git workflow falls by the wayside.

It would be a substantial improvement if you could just remove the Pull Requests tab, along with the Issues tab.




> This is the crux of the problem. GitHub spends a great deal of resources working on a mac app and a windows app, which aren't interesting to people who do things the UNIX way at all.

I don't think you understand what github is and what their goals are at all. Besides that this is bad "zero sum game" thinking.

Hint: UNIX nerds that use mutt and are perfectly happy with the standard git command-line client and using send-email or am are already served. They don't need and clearly (proven by your comment) don't want github all. Yet people clearly love github and many use the mac and windows clients. Many non-programmers are even using github for things that aren't even (entirely) code projects.

If you don't want to use pull requests or issues, just state in your README under "how to get your changes merged" and "where to log issues" what people should be doing if they want to collaborate on your project.

-----


Interested by non-code projects. Got some examples? Right now I can only think of the German law and that Wired article about Github.

-----


https://github.com/klepas/open-baskerville

-----


You couldn't just remove the Pull Requests and Issues tab. You'd need to replace it with something detail the alternate contribution workflow.

Also quick ignorant question: Does the diff patch approach eliminate the need to fork a project to contribute to it? I like the idea of forking for a project I plan on contributing a bunch to, but when I just want to contribute a bug fix or some tests, I find having to fork to be completely unnecessary.

-----


> You'd need to replace it with something detail the alternate contribution workflow.

Yes, it would be closer to an equivalent workflow if the the project owner would mention it in a README. But savvy users could send a nice patch email using only instructions in the git man pages (man git has a list of commands).

> Also quick ignorant question: Does the diff patch approach eliminate the need to fork a project to contribute to it? I like the idea of forking for a project I plan on contributing a bunch to, but when I just want to contribute a bug fix or some tests, I find having to fork to be completely unnecessary.

It does. It's quite excellent being able to do a one-off patch.

-----


> It does. It's quite excellent being able to do a one-off patch.

That alone I think is an excellent reason to support this feature and a much stronger argument than "Pull requests aren't native to git". I really wish submitting one off patches didn't require forking.

-----




Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: