-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gerrit: messy merge commits created when merges are not fresh #38920
Comments
This makes merging operation much harder. I also don't like the automatic merge commits, and try to avoid it if possible. On the other hand, making a merge commit and testing and running trybots takes time. It races with other people submitting CLs. If it rejects merge commit when some other CL went in in the interim, I guess it means it's almost impossible to do a merge during busy hours, and I have to do it in the weekend or midnight (Pacific time?). Sometimes I can do it, but it is not always feasible. |
Another unfortunate property of those commits is that it is somewhat difficult to go from commit to the Gerrit CL where code review took place, and to see the description of the (large) change. Taking commit f092be8 as an example, it has no commit message body linking to a Gerrit CL, nor does it have a Change-Id line. Searching for the hash in Gerrit returns no results: https://go-review.googlesource.com/q/f092be8fd839f5e61745c1b7f3b5990b4b8d6565 It requires viewing one of the parent commits, bed9325, which in turn has a commit message body describing the change, and a Change-Id line that makes it possible to find where code review happened: https://go-review.googlesource.com/q/I38516d6c4b41021bc61c1b9886e701de5fa2b0f1 I agree we should try to find a way to avoid this for future merges, if possible to do so without significant compromises to other favorable properties of the current approach. This issue has NeedsDecision state. What exactly is being decided, is it about re-writing history? On which branch(es)? Or is it about preventing this from happening in the future? |
Yeah, this is unfortunate, and is the part I don't really like. I wish Gerrit can link back the original CL from such commits. |
I see no problem with running the TryBots, and then rebasing the merge and immediately submitting. The result is the same, TryBots don't run on the Gerrit generated merge, and in general the Go tree doesn't operate with a submit queue, so the risk of in-flight collisions is accepted. |
Both about rewriting dev.boringcrypto, and about avoiding this in the future. This is how the rewrite looks like
|
Does gerrit have any sort of support for temporarily disabling commits to a given branch? If so then perhaps we could "turn off" commits to master while someone is preparing and submitting an important merge. |
I don't think we want to disable submitting CLs. It's good that everyone could submit CLs at their convenient time. A submit queue would be a better approach. |
I'm not convinced the Go tree has high traffic enough to require a fancier solution than rebase (as in reparent the merge) + submit immediately, which matches what we do with every CL. |
The dev.boringcrypto history rewrite is done. |
Gerrit took it upon itself to create a merge commit to merge CL 227650, itself a merge commit, because there was a commit on the target branch after the parent of the merge under review.
392a746 was created by Gerrit because d41987b was on master after the parent of e067ce5.
I am tempted to rewrite history, as the dev.boringcrypto branch is confusing enough as is, and we need it to be clean enough for it to be possible to easily flatten into a patchset.
Gerrit should definitely refuse to merge an out of date merge commit, or update it, not make a merge commit for the merge commit. Regrettably, this also happened a number of times on master for dev.link merges: f092be8, 00753d5, da33f9c, cd42fa5.
git log --graph --oneline master
is now an unreadable maze, in part because of this and in part because it's unavoidable for long-running branches that get multiple merges from master before being merged multiple times into master. Not sure what we should do about that./cc @golang/osp-team
The text was updated successfully, but these errors were encountered: