[zyxley]

So... what about using Gitlab (https://about.gitlab.com/gitlab-ce/)? It's open source (MIT license), it's a (very polished) clone of Github's functionality and workflow, and it can be self-hosted.

Someone saying "please use Github" doesn't (usually) mean they only want, specifically, Github. It means they want a tool with visual forking and merge trees, a code browser that can easily reference different branches and tags, basic issue tracking in a way that can be linked to specific commits and merges, and so on.

Honestly, at the point that Mr. Wong mentioned "no need to ever touch a bloated web browser" it felt more like ranting against ~these goddamn stupid casuals who can't even bother to use the command line!!~, not about actually bothering to even try and understand what the person was requesting.

[karmelapple]

The rant is further upheld by his username: 80x24.

Yes, the command line has its place.

Yes, some of us like GUIs even though we can do CLIs.

And using a tool that simplifies some of the trickiness of software development (filing issues, code reviews, etc) is a pretty welcome tool in my bag of tricks. An open source issue tracker is fine, but with his negative attitude towards web browsers, I assume any web-based tool that attempts to get in his software development process would be met with some level of disdain.

[erikb]

Git is one of these tools you don't use right if you don't use it in the shell. Otherwise it's like trying to fly a submarine. You might make it work if you attach enough stuff, but still it's better to use it under water or to use a real aircraft. And seriously, if you use it in the shell there is not the slightest need for Github. I love Github, but there is no additional information you gain from using it. It's just pretty.

edit: You will probably argue why you want to use git but don't want to use a shell. Please don't. If you really want to learn something, try git in a shell for a year (consistently learning, not just getting stuff done with minimal effort). If you start to use `git log` more often than any gui tool, if you merge, fork, and `rebase -i` without thinking about it, then make a decision. And if you reached that point and still think git can live without a shell, please (seriously) come back here and tell us about it.

[lomnakkus]

False dichotomy. It's quite possible to use both.

One thing that git stinks at is line-by-line code review, for example. While I don't necessarily think GitHub is especially good for that, it does do the job in a much simpler way. (Yes, I'm aware of the practice of mailing patches for review, but you're not going to convince very many people that it's better than a GUI-type thing. It also doesn't address stuff like automated pre-review and pre-merge integration test runs, etc.)

[__david__]

> One thing that git stinks at is line-by-line code review, for example.

Really? That's one thing I haven't ever seen anyone do better than plain old 'git log -p'. I use this alias:

  [alias]
      review = log -p --reverse

After `git fetch`-ing I copy the hash range that I fetched and paste it after `git review`. Then in Less I can type "/^diff" to use n and p to skip back and forth between commits. I find this is much easier to read than Github's html diff views and infinitely more efficient than the millions of clicks I need in web browser to do anything (plus there's absolutely no lag, unlike the browser).

[lomnakkus]

How are you gathering up comments and making sure that all issues are addressed, etc.?

[__david__]

By talking to the person, in person or on the phone or IM or email, depending on the priority of the question/issue. If something needs to be addressed then it goes into the bug tracker (whatever that might be). For egregious things, we might even `git revert` the patch and let the person rethink/rework it.

[lomnakkus]

That doesn't address the actual recording of the comments such that they can easily see the context of your comments. It also doesn't adress pre-merge review and pre-merge integration automated testing.

In short: No. Although I'm happy that your process works for you it doesn't (and won't) work for a lot of other situations (including mine at my current place of work nor my previous one).

[lloeki]

I wish Gitlab† had a way to do cross-instance merge requests (or more precisely real pull requests) for a completely decentralised experience.

† actually I wish Gitlab, Bitbucket and Github would support that, in an interoperable way.