I have a modified android kernel. Vendor has recently published sources for a new kernel version. Source code is published just as a zip archive. Made a repo out of it:
unzip archive.zip && rm archive.zip
git init
git branch -M master
git add -A
git commit -m "Initial commit"
In my main repo I did:
git remote add new /path/to/new/sources
git fetch new
git branch v2
git checkout v2
git merge --allow-unrelated-histories --no-commit new/master
Trying to merge new kernel version into my main repo, but I get about 70k merge conflicts. Checked a couple of them with meld as a mergetool, they don't differ at all. How do I omit conflicts if files have the same name and the same contents? I just want to deal only with different files(same name, different contents).
Thanks a lot for your replies.
CodePudding user response：
I don't think you have to start from an empty repo. In fact, you could work on your already existing repo, no need for a new one. Find out on top of what revision the zipped kernel was started from (I think this can be taken from config files in the kernel). Then, create a branch on top of the closest thing you can find on the project. Say that the kernel is based of from 5.1.4 (making up numbers here... whatever it is). Then use that tag for the new branch (choose the right tag, can't remember how they are written and I am on a cell phone):
git checkout -b other-kernel v5.1.4 # use the right tag
git rm -r * # remove EVERYTHING. Is -r necessary?
unzip the-other-kernel.zip
rm the-other-kernel.zip
git add . # add everything back
git commit -m "the other kernel"
Theoretically, that should only add the real changes applied on the other kernel. Now feel free to go to a newer place and merge.... it should be give you less conflicts like this.
CodePudding user response：
The --allow-unrelated-histories flag is the culprit here. It's wrong, although it may be the best you can do, since you might not have the necessary information available to do the right thing (i.e., provide correct history).
When you use --allow-unrelated-histories, you are telling Git: Pretend that, as the merge base of the two commits to merge, there is a completely empty commit, with no files at all. This means that every file in both histories has status A, newly-added with whatever content that file has.
When two files that have the same content are added, Git can use either version of the file, because the contents are the same. So for every file that is 100% bit-for-bit identical in your (only) commit and their final commit in their master (your new/master), Git can successfully merge these files.
For files that have different content—even if it's just one blank line or one space somewhere—Git will declare a merge conflict. If the difference is trivial, a smart "two way merge" program like meld1 may be able to merge them on its own. (Whether this merge result is correct is another question entirely: you'll need to inspect or test these results, to whatever extent you can. But that's true of all merges.)
If you cannot produce correct history—i.e., find out what Linux kernel version your sources came from, and make your commit come after that commit—so that Git does not have the correct merge base, you may have to figure out how to run meld, or some similar tool, over all the conflicted files to reduce the conflicts to those that are manageable.
1According to its advertising, at least, meld will do both "two way merge" (i.e., combine version A and version B by guessing) and a standard three-way merge (look at some base version to see what changes happened in both versions A and B, and combine the changes rather than just guessing). Combining changes, in the three-way merge style that Git uses, is clearly superior, but even then a computer program is still guessing, as these programs do not understand the semantics of the input texts.
(Any time someone says that you're arguing "mere semantics", you can reply: "Okay, we'll jelly sandwich this conniption. Let's brumblefrotz!" If they don't understand what you just said: "Who cares? That's just semantics!" Since semantics literally means "meaning", "mere semantics" means they don't care about meaning. See https://people.howstuffworks.com/semantics.htm. And yes, I am pedantic, and sometimes a bit grouchy.