Ok, so what I've figured out is that it seems gerrit doesn't like it when the
code gets refactored. I have several commits that are showing merge conflicts
but the files that have conflicts are because a lot of code changes between
them as things get refactored. Entire blocks of code in some f
Dear Jeff,
Am 12.01.22 um 15:49 schrieb Jeff Daly:
Ok, so what I've figured out is that it seems gerrit doesn't like it
when the code gets refactored. I have several commits that are
showing merge conflicts but the files that have conflicts are because
a lot of code changes between them as thi
Ok that sort of makes sense, but for example in the case of the XHCI patch, the
merge conflict appears to be that since soc/intel/denverton_ns/xhci.c was
changed completely to reflect the usage of the common code and shouldn't cause
an issue with being cherry-picked onto master...
So, I jus
Hi Jeff,
those merge conflicts are only there for cherry-picking the specific
patch without the ones before it directly on top of the current top of
tree. When the patches before that one in the patch train are submitted,
the merge conflict will disappear, so while this might look like a
prob
If I don't have to do anything, then I won't. I wasn't sure whether commits
that are marked with conflicts tend to get less attention than ones that don't.
I've been rebasing for amending earlier commits so I guess at least I'm doing
that correctly. What I'm confused with is as you said, i
Ah right. Too many changes to keep track of in my head. I guess that's what
good tools are for. In any case, as long as the commits are in small enough
bits for reviewers to check in the context of the refactoring I'm doing then it
shouldn't matter. I should done soon, pushing the remaining
6 matches
Mail list logo