dealing with rebase-update conflicts

[anatoly techtonik]

Is there a good way to avoid merge conflicts after a "cl upload" branch

with multiple patchsets as commits was rebased and submitted upstream?

https://bugs.chromium.org/p/chromium/issues/detail?id=706503

[Nodir Turakulov]

+iannucci 

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/93840afb-da65-4497-9b3f-f7329648767b%40chromium.org.

[Robert Iannucci]

So `git rebase-update` is supposed to do this, but it's not perfect, especially if a lot of changesets happen which interact with each other.

It may be worth looking into tweaking the rebase-update algorithm a bit to be a bit smarter. One thing we could do would be to directly ask gerrit what the landed commit hash was and then keep an eye out for that during the rebase.

Running rebase-update tends to be more successful if it's run pretty often, and gets less successful the more commits land between your CL and the time you run it.

Other than that I don't have a lot of ready advice.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAFckvjXsbgyPxSmFvQxL0BuvLJ1Drp%3DSimjxvOFqGNY%2BVE6kRA%40mail.gmail.com.

[anatoly techtonik]

My understanding of the issue is that `git rebase-update` should
repeat the operations made on Gerrit side locally, and when the commit
is merged properly, rebase the branch. If I understand it correctly,
Gerrit squashes all branch commits into one, and them rebases them on
top of master. 'git rebase-update' should do the same and report if
anything from this process does not work.

At least squashing the branch seems like the most obvious thing to do
if the change was merged. Maybe ask user to squash, which can be also
useful for testing separately.

--
anatoly t.

[Robert Iannucci]

So rebase-update does do a squash, if it fails to rebase normally. Roughly it does:

• regular rebase
  
• if successful
• if diff is empty : delete the branch
• else : keep the branch
• else
• squash the branch
• rebase the squash
• if diff is empty : delete the branch
• else : unsquash, report error

The problem you run into with many overlapping changes is that last else case; even with a squashed branch, the rebase process still doesn't work, because git is confused when it tries to merge the squashed branch with the other overlapping changes.

Something that rebase-update maybe could do would be to squash multiple feature branches together as a 'guess' and see if that rebases cleanly... however I'm not sure what heuristic to use there that wouldn't be very slow.

There's also the possibility to tie rebase-update to gerrit directly and query for the state of the CLs and just delete their corresponding branches. This would make rebase-update useless for any other repo hosting service or code review tool, but it would probably work for chromium.

R

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAPkN8x%2BhAOHcDN3EYYiP8FGF35T7nC9cLfUA0ffE%2BDT9BOdMzg%40mail.gmail.com.

[anatoly techtonik]

I didn't save a copy of repository to test this (there is no undo in git, right?).

Doing `git rebase --skip` helped. And still I don't understand the log at:

https://bugs.chromium.org/p/chromium/issues/detail?id=706503

Last words from rebase-update were:

   Rebasing: rewinpath

   Failed! Attempting to squash rewinpath ... Failed!

Which indicate that the first operation in the else branch, but there are

two issues:

1. How can squash at all fail?

2. I have to deal with rebase conflict of 1st changeset from 4 in

    https://chromium-review.googlesource.com/c/461141/1 - this code

    should no longer exist if all 4 changesets are squashed.

The only explanation is that the working copy was not cleaned

after failed rebase, and that's why "else squash" failed.