New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 751901 link

Starred by 11 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Cannot Have Multi-user Dependent Changes on Gerrit without following the deltas in lock-step

Project Member Reported by robliao@chromium.org, Aug 3 2017

Issue description

> git cl patch 594713
From https://chromium.googlesource.com/chromium/src
 * branch                      refs/changes/13/594713/6 -> FETCH_HEAD
Committed patch for change 594713 patchset 6 locally.
Note: this created a local commit which does not have the same hash as the one uploaded for review. This will make uploading changes based on top of this branch difficult.
If you want to do that, use "git cl patch --force" instead.

[Create a dependent branch]

> git cl upload
Upload upstream branch runloop first.
It is likely that this branch has been rebased since its last upload, so you just need to upload it again.
(If you uploaded it with --no-squash, then branch dependencies are not supported, and you should reupload with --squash.)

I shouldn't have to follow the dependent branch in lock-step just to upload a delta. This adversely affects projects where changes need to depend on one another from different developers.

The bar here should be cherry-pickability. Following gerrit's internal branch structure should not be necessary.


Another variant of this bug is chained deltas.

Uploaded: A1 <--- B1 <--- C1
Local:    A1 <--- B1 <--- C1

Suppose you've done some work on A1 and want to fix a nit on C1, so now your branches look like...

Uploaded: A1 <--- B1 <--- C1
Local:    A2 <--- B2 <--- C2

You're not ready to upload A2, but C2 has just a nit. There's no way to upload C2 without uploading A2 and B2.

 
Description: Show this description
Description: Show this description

Comment 3 by brettw@chromium.org, Dec 13 2017

I have run into this problem on multiple occasions. In Chrome, the commit queue can take a long time. If I have started a commit queue run on a patch, I *really* don't want to upload a new one just to rebase it.

But if I ever get into this state, I'm prevented from uploading secondary patches. I have resorted to emailing myself patch files to transfer between computers.
 Issue 762081  has been merged into this issue.
Components: Infra>SDK
Labels: -Type-Bug Type-Bug-Regression
Status: Available (was: Untriaged)

Comment 6 by aga...@chromium.org, Mar 27 2018

Cc: jrn@google.com logan@google.com
 Issue 750924  has been merged into this issue.

Sign in to add a comment