I figured out how to cherry-pick between two repositories by setting up a remote, however, my repositories have slightly different file structures because the top-level folder name is not identical, and a conflict occurs that the file the cherry-pick commit modifies does not exist because, I assume, it's not drilling down past the differently-named folder.
For example:
Source repo: NameA\Content\Policy\File1.htm
Origin repo: NameB\Content\Policy\File1.htm
I assume that because NameA does not equal NameB, a cherry-picked commit that contains File1 between the two repos conflicts/fails because it cannot find NameA... there is only NameB in the repo I want to cherry-pick to. I cannot make these Names the same. When I cherry-pick as is, it creates a new NameA folder next to NameB when what I want is for it to update File1 under NameB with the commit changes.
Is there any way to guide the cherry-pick past the NameA/B difference?
I have tried looking into git-checkout-index and patch but I'm not sure those are plausible. Ideally there is some way to modify my git cherry-pick <commit> command to ensure it doesn't conflict but I cannot find that way.
I tried:
git cherry-pick --strategy=subtree <commit>
And it seems to have figured out that I want NameB's file updated, but I get a CONFLICT (modify/delete) still.
Appreciate any help, not very experienced in Git.
One hack you could try to ease off the work for git is to create a new commit that has the path as it is in the target branch and then cherry-pick from there... something like this... Suppose that you want to cherry pick commit X into branch target-branch (we do not care about the remotes, right?).
And now suppose that if you cherry-pick X into target-branch you get a problem like what you are describing.... on target-branch a file is named foo/file1 and on X the file is bar/file2 and git could not see that when cherry-picking.... so, you could do this:
git checkout X~ # working on detached HEAD.... no problem. Keep the pigtail!!!
git mv bar/file2 foo/file1
git commit -m "Renaming file as a hack"
git cherry-pick X
# git should be very happy to do that cherry-pick
Now git should have no problem detecting which file you were talking about on X when cherry-picking into target-branch
git checkout target-branch
git cherry-pick HEAD@{1}
I wouldn't be surprised if you get conflicts from this..... but at least git should not be confused that there are changes coming into foo/file1.