4 ms·

So... what about using Gitlab (https://about.gitlab.com/gitlab-ce/ https://about.gitlab.com/gitlab-ce/)? It's open source (MIT license), it's a (very polished)

• lloeki 12y ago
  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.
• erikb 12y ago
  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 12y ago
    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__ 12y ago
      > 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 12y ago
        How are you gathering up comments and making sure that all issues are addressed, etc.?
        • __david__ 12y ago
          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 12y ago
            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).
• karmelapple 12y ago
  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.