title: Shouldn't git branch --no-merged list new branches?
body: <p>We have a large number of central git repositories and use branches to track work on various projects. When a project finishes, we merge to master and push to origin.</p>
  
  <p>When starting a new project, I'd like to list any other current work on that repository, as a heads-up for the developer (e.g. so they can communicate their release plans). <code>git branch --all --no-merged origin/master</code> seems promising but apparently it only lists branches that have commits. Conceptually, even newly created, "empty" branches state the <strong>intention</strong> of doing some work, so shouldn't these be listed too?</p>
  
  <p>I suspect that this may be related to the distinction between a branch and a branch head, and while the branch head points to its start point there is nothing to merge. But since merges are explicitly recorded in history (right?) shouldn't it be possible to identify even "empty" branches as unmerged? Can this be done?</p>
  
  <p>An obvious workaround is to force a dummy initial commit in each new branch but I'd like to avoid this if possible. And it seems developers should not have to push their unfinished changes if they don't want to (so I expect most branches in the central repository would remain empty until their project is completed).</p>
  
  <p>Example:</p>
  
  <pre><code># Alice creates and pushes branch1
  git clone $REPO clone1
  git checkout -b branch1
  git push -u --all
  # ...continues development in her local repository...
  
  # Bob wants to know if anybody is working on $REPO
  git clone $REPO clone2
  git branch --all --no-merged origin/master
  # no output - he doesn't realize Alice is working in the same repository
  </code></pre>