3

There is a cherry-pick command in the git which allows me to copy some commit on top of the current. However, it does some conflict resolution, that I do not care about. What is alternative to cherry-pick which just copies picked commit over on top of current commit?

I can do it manually: select desired commit, copy its files, save them into non-managed folder, select current commit which will be the base for new one, copy the archived files into the git working folder. Separately, I have to copy the commit message. This is huge hassle that I do currently to avoid the change conflicts. Which command can help me to achieve the goal automatically?

Valentin Tihomirov
  • 1
  • 1
  • 6
  • 28
  • Just a word of caution. In the general case, do not expect things to always work just because you favour the cherry-picked commit in case of conflicts. Doing this may result in code breaking and no longer being compilable. – Alderath Dec 09 '15 at 08:59
  • @Alderath Of course, I will fix the new commit and check the results. So, it will be a merge anyway but with less hassle. Merges always can result in errors, even if git says that it is resolved, I could have bugs anyway. However, I know that all changes must concern only single file whereas all commits must have all other files identical. This will help me to focus on the feature that differs along the commits. I want commits to be identical otherwise. Forcing the other files to most up-to-date is what will enable me to propagate the to-be-common part easily. – Valentin Tihomirov Dec 09 '15 at 13:16

1 Answers1

5

You could use the merge strategy option 'theirs':

git cherry-pick <SHA-1> -Xtheirs

Where <SHA-1> is the hash of the commit you want to cherry pick into your branch.

This means that, in case of conflict, Git would always resolve it with the version of commit being cherry-picked ("theirs").

Note that, even without that option, you can do the same manually (but that would not scale well with many files)

git cherry-pick <SHA-1>
error: could not apply <SHA-1>... [Commit Message]
hint: after resolving the conflicts, mark the corrected paths

git checkout --theirs path/to/conflicted_file.php
git add path/to/conflicted_file.php
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks. Using `that_branch` name instead of `` id seems to work as well. – Valentin Tihomirov Dec 09 '15 at 10:52
  • Curiously, I had two identical invalid forked commits, A and B. I have fixed A => A2 and then put B on top of the result A2. Now, I checked out this B on top of A2 but the fixed place looks like A2. I am happy that it is fixed but I wonder why B did not override this place? The allele is different in A2 and B. There must be a confilct and B should prevail, with option −Xtheirs-Xtheirs. Isn't it? – Valentin Tihomirov Dec 09 '15 at 13:32
  • @ValentinTihomirov Yes, B should prevail in case of conflict. "Now, I checked out this B on top of A2 but the fixed place looks like B": isn't that a sign that B has prevailed, as expected with option `-Xtheirs`? – VonC Dec 09 '15 at 13:34
  • Sorry for the typo. I have corrected my comment. I was excited because `fixed place looks like A2`. – Valentin Tihomirov Dec 09 '15 at 13:39
  • @ValentinTihomirov Then it means there was no conflict on those particular lines: `-Xtheirs` only applies in case of conflict. – VonC Dec 09 '15 at 13:47
  • But these parts are certainly different! Which one will it take? – Valentin Tihomirov Dec 09 '15 at 13:52
  • @ValentinTihomirov were they modified concurrently though? – VonC Dec 09 '15 at 13:52
  • Yes, both files were introduced in parallel and are slightly different copies of each other. I wonder why git prefers current branch copy even if −theirs-theirs is given a preference. I tried to reproduce, creating small demo and no other changes but this one. But, it picks B edition of the allele in small demo. – Valentin Tihomirov Dec 09 '15 at 14:13
  • Ok, freenode#git clarified the situation. Git picks only changes. Because changes were done in A and not in B, it will not notice the refactoring, which seems ok to me. – Valentin Tihomirov Dec 09 '15 at 15:11
  • "Because changes were done in A and not in B": that means no concurrent changes, as I suspected earlier! (at least not for the part of the file where A prevailed) – VonC Dec 09 '15 at 15:15
  • `not concurrent changes` because I am not familiar with git terminology. I suspected that I must consider all changes since common root. There was no such file in the common root and I decided that all changes from root to the target A and B must be accumulated meaning that I have got two different versions of a file at the same time. But, git somehow realized that the files were identical in A and B when first introduced concurrently and then refactored in A. Therefore probably it picked A version as necessary change, more important than current state of B. – Valentin Tihomirov Dec 09 '15 at 15:23
  • @ValentinTihomirov I agree: if that file was created (not modified) concurrently, then changes in A would be preserved. – VonC Dec 09 '15 at 15:28
  • Here is [the case](http://stackoverflow.com/questions/34187857) that concerned and puzzled me. – Valentin Tihomirov Dec 10 '15 at 00:06