CODEWITHSUNDEEP
git
kiran bobbu
kiran bobbu

Reputation: 143

git patch apply leading to conflicts?

We need to upgrade the kernel for android from <REV1> to <REV2>.

I am trying to generate a list of patches between two <REV1> and <REV2>. So I checked if both are on the same branch to get that list of patches using command

$git merge-base 69ecc39b5b4ea78de1f25bf9cbe7c236a91f764c af5ddc99f3d0e7c2406d5bf64763eef7d0843127

and found that they are not on same branch. as I got the first common ancestor of <REV1> and <REV2> as c4b646ff80f558010ee486421ee1b718db1a3193

So I tried to generate a list of patches between the common ancestor and <REV2> using 

$git format-patch c4b646ff80f558010ee486421ee1b718db1a3193..af5ddc99f3d0e7c2406d5bf64763eef7d0843127 -o patch_JUN15_NOV26

Now I created a new branch and reset that to common ancestor commit 

$git reset --hard c4b646ff80f558010ee486421ee1b718db1a319

Now I tried to patch the whole list of patches on this branch:

$git am --ignore-whitespace --reject ../../jb/kernel/patch_JUN15_APR10/*

But I got patch failed error asking me to resolve the conflicts for the first patch in the patchlist . But I expect no conflicts. My assumption is that if <REV1> and <REV2> are on the same branch, then the generated patch list from format-patch can be applied back on <REV1> smoothly without conflicts.

Is my assumption correct? Am I doing it the right way?

Upvotes: 2

Views: 912

Answers (1)

Kaz
Kaz

Reputation: 58627

The straight git answer, probably wrong:

Create new branch merge-branch at REV2, then rebase the REV2 changes newer than the ancestor (and thus not in REV1) over top of REV1:

git checkout -b merge-branch <rev2-hash>
git rebase <ancestor-hash> --onto <rev1-hash>
             ^                        ^
             |                         \
             |                          `play them on top of this
              `take commits from this
               far back in the current branch

      ... and plant the result as the replacement for the current branch

The bigger picture:

Why the above answer is probably wrong is because, I'm guessing, like many, you're a small organization who maintains some customizations of the kernel for your product, and you want to upgrade to a newer kernel. You based your customizations on REV1 and now you would like to move that work to REV2. If that is the case, then dealing with the merge between REV1 and REV2 is completely the wrong problem. This has already been taken care of upstream. Upstream has produced two perfectly good kernels: REV1 and REV2. REV1 isn't a direct ancestor of REV2, because those kernels are actually branches. But you don't have to deal with these change management details. All you need to do is rebase your changes that were done against REV1 on top of REV2.

Suppose you have ourbranch of kernel development which sprouted from REV1:

First, create a clone of ourbranch called ourbranch-REV2:

git checkout -b ourbranch-REV2 ourbranch

Now, rebase the ourbranch changes that are new since REV1 (i.e. only our local changes), on top of the REV2 kernel:

git rebase REV1 --onto REV2

If all goes well, you have ourbranch-REV2 which is your ourbranch history rewritten as if it had been developed over the REV2 kernel.

Upvotes: 1

Related Questions