Menu
I've been using git-format-patch and git-am to apply changes from one repository to another. The file structures are the same but there are some changes in the repository I'm apply to which cause most patches to fail a few hunks. But most of the patch hunks apply with a little but of fuzzyness in the line numbers.
As far as I can tell git-am apply a very strict interpretation so rejects all these patches outright.
So my workflow has become
$ git am ../the-patch.patch # Fails because the patch doesn't apply cleanly $ patch -p1 < ../the-patch.patch # Applies most of the hunks, leaves .rej files for the ones that conflict # Fix the conflicting hunks manually $ git am --continue It would be nice if I didn't have to run the command line patch and could just have that happen as part of the am command.
Running with the --reject flag seems to create a .rej file with all the hunks in the file if any conflict, which isn't what I want.
Running with the --3way flag fails with
fatal: sha1 information is lacking or useless (the-file.java). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Which I presume is because the change set this was based on is not in the repository I'm merging to.
Is there any way to make git-am apply the patch with fuzzy matching like the raw patch command does and only create .rej files containing the hunks that failed?
570
GIT patch or GIT diff is used to share the changes made by you to others without pushing it to main branch of the repository. This way other people can check your changes from the GIT patch file you made and suggest the necessary corrections.
A patch is usually skipped when the changes it contains were already applied in the past. There are many possible reasons for this: a merge, a cherry-pick, changes operated manually or using another patch etc.
Patch is a text file, whose contents are similar to Git diff, but along with code, it also has metadata about commits; e.g., commit ID, date, commit message, etc. We can create a patch from commits and other people can apply them to their repository.
If i understand you correctly you trying to merge code form 1 repo to another one and you are failing on some parts of your code. You then fix it manually and from now on you want it to be merged without any errors.
In this case you should use git rerere
In a workflow employing relatively long lived topic branches, the developer sometimes needs to resolve the same conflicts over and over again until the topic branches are done (either merged to the "release" branch, or sent out and accepted upstream).
This command assists the developer in this process by recording conflicted automerge results and corresponding hand resolve results on the initial manual merge, and applying previously recorded hand resolutions to their corresponding automerge results.
git config --global rerere.enabled true If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
