As a suggestion, I think you should include the list of features you wrote in this thread in your readme. That list made me really want to try out the tool. If I had only read your readme on github I would not have been as interested.
Cheers for that. I passed the github link and your list of features to the guys I used to work with on the Enterprise project I mention below. If it solves any pain I'll try to let you know :)
On an Enterprise project I was on recently this was a real problem. With about 12 distinct and large (5-10 developers per team) all working on a single git repo, the lingering branches were out of control. They had built up over more than a year of abuse.
I think this issue is worth thinking about. For projects with a single owner or a small core set of contributors taking pull requests it is manageable. But when the responsibility is distributed, especially in the degenerate culture of Enterprise Java, uncontrolled branching can make git usage miserable.
The real problem was that we were using Git like an SVN server. But it was really interesting to see how bad it can be when branch pruning is not considered upfront.
Did you consider using forks more actively? E.g. each team has it's own fork where they commit, and one person is responsible for merging the fork upstream?
I second this. We really enjoyed the one fork per user model. Each fork's owner was responsible for their own branches, which was much more manageable.
That's really the way Git was designed to be used. Trying to use Git in an SVN model is doable, but suboptimal and likely to lead to the types of issues the parent comment was complaining about.
Way to go Github! I think it is quite clear that pull requests are the best feature of Github and a boon to the OSS community in general. This feature is a welcome tightening.
What makes you think that is the case? It looks equivalent to a "git merge --no-ff <feature-branch>" to me. The feature branch is then merged with master (or whatever the target branch was) and would appear if you ran "git branch [-r] --merged" from the target branch which is a good hint that it can be safely deleted.
* Which remote branches are empty (all code is in master), also outputs a command to delete them all.
* Which remote branches still have lots of code that needs to be merged
* How long remote branches have been waiting to be merged.
.
Why is this useful?
* discover which projects are languishing
* discover which engineers are unhappy that their code is not being reviewed/merged
* discover how effective your development process is