* When you say "all branches starting with branch-heads/42", do you mean "all branches since 42", so this includes even the most recent branches?
  - If so, how is this happening? Shouldn't recent branches be branched off of master? I would expect *older* branches to be the ones with disparate history, for example if someone rewrote the history of master.

* That aside, this seems like a real bug. I'm not sure why `gclient status` needs to call `git merge-base`. That should be removed, or should be skipped/ignored if it fails.

> * When you say "all branches starting with branch-heads/42", do you mean "all branches since 42", so this includes even the most recent branches?

Yes, all the way to branch-heads/53.

>  - If so, how is this happening? Shouldn't recent branches be branched off of master? I would expect *older* branches to be the ones with disparate history, for example if someone rewrote the history of master.

I don't know either, I've only noticed this myself when moving a checkout from M51 to M52; I guess the WebRTC team and the people who migrated that repository to git probably know more about this. What I can see is that recent branches (branch-heads/50 to 53, and some others such as 45) all have a linear history dating back to that commit I mentioned, and all commits in the branch-heads (and thus not master) have a "Cr-Mirrored-Commit" line referencing an identical commit in master's history line.

> * That aside, this seems like a real bug. I'm not sure why `gclient status` needs to call `git merge-base`. That should be removed, or should be skipped/ignored if it fails.

I was considering sending a patch that does this, but decided to file the bug first in case this was done by design and the repositories needed to be fixed instead. There are a few other places that call git merge-base in gclient_scm.py (GitWrapper.diff() and GitWrapper.pack()), I'm not sure if they should be adjusted too.

+kjellander who might be able to describe this seemingly-crazy branching scheme.

I think iannucci changed diff/status to use fancy diffing against the merge-base. Robbie, can you explain alternatives that might work in this case?

Erm... If I changed it, it was years ago, but I don't recall doing anything with gclient status. Maybe it's used to show how far behind/ahead of the master branch the current repo is?

In any event, it should cause a ??? result rather than a failure if there's no common ancestry. I don't know what the merge-base information is used for, or if simply removing it will be fine.

The call to git merge-base seems to have been introduced with git support itself in https://codereview.chromium.org/235005.

I've just sent https://codereview.chromium.org/2215673002/ as a way to work around failed git merge-base calls.

Like I explained in my comment in the CL, I'm not entirely convinced we need the calls to merge-base: it seems to be used as a way of telling the calls to git diff to return all changes since the current branch was created from master, which does not make much sense on release branches or any branch not created from master. I think the code in GitWrapper.update() does a better job at finding what to compare the current HEAD against, but the logic there is quite convoluted and moving the code around will likely break something.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/05c835919467e87b13c39c687cdbe659300784ea

commit 05c835919467e87b13c39c687cdbe659300784ea
Author: raphael.kubo.da.costa <raphael.kubo.da.costa@intel.com>
Date: Thu Aug 04 15:32:41 2016

gclient_scm: Make calls to "git merge-base" non-fatal.

It might be the case for some repositories that there is no merge base
between the current git HEAD and origin/master, which causes git
merge-base to exit with a non-zero code and cause calls to gclient
status/diff/pack to fail, as well as gclient sync if the repository in
question has been removed from DEPS.

This is true for the external/webrtc/trunk/talk repository, for example.
Its recent release branches (branch-heads/45 all the way to /53 at
least) have no ancestry shared with its master branch, so gclient
sync'ing from a Chromium M51 checkout to an M52 one (where it's no
longer in DEPS) fails because of the failed git merge-base calls.

We now ignore failures and just don't specify a merge base when calling
"git diff".

BUG= 633962 
R=iannucci@chromium.org,agable@chromium.org,maruel@chromium.org

Review-Url: https://codereview.chromium.org/2215673002

[modify] https://crrev.com/05c835919467e87b13c39c687cdbe659300784ea/gclient_scm.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/build.git/+/3a5ab4aa0fd7281b584849dd84658000fe4a46ff

commit 3a5ab4aa0fd7281b584849dd84658000fe4a46ff
Author: recipe-roller <recipe-roller@chromium.org>
Date: Thu Aug 04 15:46:57 2016

Roll recipe dependencies (trivial).

This is an automated CL created by the recipe roller. This CL rolls recipe
changes from upstream projects (e.g. depot_tools) into downstream projects
(e.g. tools/build).

More info is at https://goo.gl/zkKdpD. Use https://goo.gl/noib3a to file a bug
(or complain)

depot_tools:
  https://crrev.com/05c835919467e87b13c39c687cdbe659300784ea gclient_scm: Make calls to "git merge-base" non-fatal. (raphael.kubo.da.costa@intel.com)

R=agable@chromium.org,iannucci@chromium.org,raphael.kubo.da.costa@intel.com,maruel@chromium.org
BUG= 633962 

TBR=martiniss@chromium.org,phajdan.jr@chromium.org

Review-Url: https://codereview.chromium.org/2213013002

[modify] https://crrev.com/3a5ab4aa0fd7281b584849dd84658000fe4a46ff/infra/config/recipes.cfg

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/build_limited/scripts/slave/+/db8cda163af919f135021a543d606d550df1e2ca

commit db8cda163af919f135021a543d606d550df1e2ca
Author: recipe-roller <recipe-roller@chromium.org>
Date: Thu Aug 04 15:58:37 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/infra.git/+/ed7f399ae811508504224c33315ba52f5070adba

commit ed7f399ae811508504224c33315ba52f5070adba
Author: recipe-roller <recipe-roller@chromium.org>
Date: Thu Aug 04 16:07:14 2016

Roll recipe dependencies (trivial).

This is an automated CL created by the recipe roller. This CL rolls recipe
changes from upstream projects (e.g. depot_tools) into downstream projects
(e.g. tools/build).

More info is at https://goo.gl/zkKdpD. Use https://goo.gl/noib3a to file a bug
(or complain)

build:
  https://crrev.com/3a5ab4aa0fd7281b584849dd84658000fe4a46ff Roll recipe dependencies (trivial). (recipe-roller@chromium.org)
depot_tools:
  https://crrev.com/05c835919467e87b13c39c687cdbe659300784ea gclient_scm: Make calls to "git merge-base" non-fatal. (raphael.kubo.da.costa@intel.com)

R=iannucci@chromium.org,maruel@chromium.org,raphael.kubo.da.costa@intel.com,recipe-roller@chromium.org,martiniss@chromium.org,phajdan.jr@chromium.org,agable@chromium.org
BUG= 633962 

TBR=martiniss@chromium.org,phajdan.jr@chromium.org

Review-Url: https://codereview.chromium.org/2214823002

[modify] https://crrev.com/ed7f399ae811508504224c33315ba52f5070adba/infra/config/recipes.cfg

Thanks for the CL, I think that was the right fix.

I'd still really like to hear from kjellander about why those release branches don't share history with master, and what we can do to get future releases to be branched from master again, so assigning this bug to him.

I must have missed this one. 
We create our branches according to https://sites.google.com/a/google.com/rtc-platform/releases/release-how-to#TOC-Create-a-WebRTC-branch-in-Git but I don't see anything that would explain why they don't have a common merge base with master.

My guess would be that the fact that we're using a Git subtree mirror (of the webrtc/ dir of the main repo) in Chrome's src/third_party/webrtc is the explanation.

Closing as fixed since it seems the CL above solved the problem for the reporter.