GitHub releases integrated issue tracking
github.com
github.com
* There does not seem to be any documentation
* What are keywords to close a task in a commit. Does it have to be in English? Can the words be customized?
* Can I import from external projects (i.e. Everyone on github uses something else today and needs to migrate)
* Where are issues stored? Are they stored in a git repo?
* Can I export?
* When you make a label shouldn't it pick a color automatically?
* What about when I merge issues from forked projects, when they Close task #12 is that their #12 or my #12?
* If I rebase and remove a commit that fixed #12 will the issue be updated?
* If you fork someones repo do you get the issues? What about when you pull and rebase? How are they merged?
* Can I see if any of my forks have fixed issues?
* What branch does the issue tracker look in to see if an issue has been fixed? master? Is it customizable?
It looks nice, but after poking at it for a minute I am a bit underwhelmed. It is a nice basic and traditional issue tracker, but at least what is exposed is no where near any of the interesting issue trackers built on top of git that people have been playing around with the past year. Maybe it is all built on git and that will be revealed as time goes on, but not sure. Hopefully it wont stop some of the people who have been playing around with issue trackers built on top of git. Part of the joy of Git is that I am not tied to GitHub. Yes I host my projects there, but when it goes down it doesn't matter because I can still keep working. I was really looking forward to a issue tracker that is built on git that I can store in my project tied into GitHub. But this is till very cool and a good step in the right direction.
That's exactly what it's meant to be. We're not in the business of building fancy bug trackers :)
I see very little reason to use anything other than GitHub for new open source projects.
Here's an easy improvement: how about integrating a CLA submission form, so contributors can easily e-sign a project's CLA, and project managers can easily see who has signed the CLA.
[1] Obviously some things would be more difficult with say, svn, but my point is, I use git to use github.
(edit, missing word, edit2, stupid asterisk formatting)
Having git be universal in the Ruby/Rails world has been a huge accellerator for maintaing open source projects. No longer are we subject to core teams losing interest, anyone can fork and become the new core team.
It's not like it wasn't possible to fork stuff in the past, it just required a little bit more effort... enough so that you didn't just get random copies of stuff all over the place.
I wonder if you get a projects bugs if you fork it?
An indicator for the original code would maybe be useful, but it would lead to confusion when, for example, the original maintainers fade away and another repo becomes the pseudo-canonical tree.
Furthermore, trying to implement fork queues, pull requests, and even proper contributor attribution atop Subversion would be a ridiculous amount of work for very little gain.
Regardless, if you really want to stick with Subversion, you might at least consider setting up a cron job that fetches to a local git-svn mirror and then pushes a clone to GitHub. You won't have to learn a whole new version control system, and your users will happily run circles around you with their ability to fork, branch, and merge before you can copy your source tree into a new tag.
So that still makes it a very interesting project. GitHub's issue tracking is not bt integrated into the repositories from what I can tell.
Good work Logical Awesome.
As soon as they get their act together and make every page load in milliseconds as opposed to seconds, we're dumping our own git server.
That said, we're still working hard to optimize and speed-up every aspect of the site. The dashboard in particular should get a massive speedup soon.
Alright github, I forgive you for all the downtime!
I guess I'm really asking what's the advantage of distributed version control over centralized for Joe Coder. Distributed VC seems quite different, and I'm wondering whether it's worth the time to learn. Or should I just get on with writing code using the VCS I'm used to?
The way that git deals with branching is great. I'm a real fan of the way that it lets me context switch. This feature isn't a result of git's distributed nature, but I think it's worth switching VCS's for.
One of the advantages it certainly gave me is that there isn't any difference between the local and remote repositories. There aren't any daemons to start and no infrastructure to keep up; just initialize your repo and go!
`git init` and you've got a local repo. One .git folder in your root directory and that's it. Blow away the one folder and you're back to where you started. None of the .svn folder spam you get with subversion.
There are a few differences in commands and concepts, but you can keep it simple and the experience is about the same for small to medium independent projects.
I setup a new repository last night and saw an option for "issues" in the settings, so I'm not so surprised but definitely happy :)
GitX is more useful, but I prefer the IA of gitnub for history browsing.