Andrii, please reassign if you are not the right owner.

owner is either me or agable@. but, I don't actually see this as a bug, yet.

git cl patch does cherry pick of 1 commit from HEAD of ref/change/xx/yyyy to apply just the patch from a CL yyyy, and not everything it might depend on (which is actually not trivial to figure out).

hence, if your change B really depends on change A on master branch, then applying B on top of master should fail, and apparently it did, so WAI by me.

Or, are you thinking that git cl patch B should actually apply A and B?

I expected git cl patch B to apply both A and B. That is what apply_issue.py does and what the recipe does as well (IIRC).

well, apply_issue's main purpose was the bots, and recipe just shells out to apply_issue. 

git cl patch for Rietveld only applies B, not A. I made Gerrit the same, because **to me** this made sense.

Assume git cl patch B would apply both B and A. Then, I see two problems:
* git cl expects that 1 branch <=> 1 CL. Applying A and B on the same branch brakes this.
* related, how do I apply just B?


Am I missing something?
If so, let me know.
If not, then my answer to this bug would be to emit a warning that "CL B has dependencies, which won't be applied."

I disagree that apply_issue's main purpose was the bots, it actually worked much better for developers to apply patches locally than "git cl patch" did. See https://bugs.chromium.org/p/chromium/issues/detail?id=489063.

If we are going to not support Gerrit in apply_issue (see https://bugs.chromium.org/p/chromium/issues/detail?id=651039) then we should have an equivalent substitute that does the same else it is a regression?

I'd say it should work something like this:
1) Don't use cherry-pick, just check out the commit that you fetched from gerrit.
2) If the parent of that commit is also a gerrit CL, and doesn't exist in the branch that "git cl patch" is being run on (i.e. the user hasn't previously run "git cl patch" on the parent CL), abort and print a warning and instructions.
Eventually 3) Offer to automatically construct the parent branches too

That said, I disagree with rmistry's comment in 3. I expect gerrit's "git cl patch" to do the exact same thing as rietveld's, which is fail if you haven't patched in a dependency.

We can reconsider that behavior later, but the drive towards launch is not the time.

"""
That said, I disagree with rmistry's comment in 3. I expect gerrit's "git cl patch" to do the exact same thing as rietveld's, which is fail if you haven't patched in a dependency.
"""
I agree with this if apply_issue.py did the same thing with Gerrit issues that it does with Rietveld issues (handle dependencies). Since it does not then it is a regression that currently no tool in depot_tools deals with. I will be happy to mark this as work as intended and file a new one for apply_issue.py (or just rename this issue). IMO a regression like this should be a launch blocker.

Having thought about this some more I would be happy with:
* Before launch: Adding documentation saying "git cl patch" does not apply dependencies of a change. This will be useful to remove confusion about apply_issue.py not being supported and "git cl patch" not supporting dependencies. Also in the documentation it can list that if you want to apply dependencies then do this command: "git fetch https://skia.googlesource.com/skia refs/changes/xx/yyyy/z && git checkout FETCH_HEAD".

* After launch (or not at all): Doing what agable@ listed in https://bugs.chromium.org/p/chromium/issues/detail?id=678992#c6.

This bug as its title goes is an AfterGlow to execute upon what agable@ wrote in #c6 above.

Lack of apply_issue equivalent in Gerrit world is  issue 682054  .

git-cl-patch has been massively modified and upgraded, and now handles this case well.