I am trying to select/edit changes from another branch before merging - e.g., after a fetch.
When there are conflicts, it is easy to go to a conflicted file and remove/edit the text between '>>>' and '<<<'. But when there is no conflict it seems that the usual way is to edit hunks like I have found in some answers answer1, answer2:
git checkout -p
or
git add -p
However, despite the simplicity of the hunk editing, a single (after splitting) long hunk sometimes is not practical to be correctly edited. I suppose the difficulty comes when the number of lines changes or ' ' lines are unwittingly removed or transformed into '+' lines. Another problem, maybe even more important, is that the whole file is not available. There are text gaps between hunks that otherwise could make editing more comfortable.
One solution I think of is to simulate all changes as conflicts. Is that possible? This answer suggests a complex sequence of commands with a comment suggesting a equally complex (to be used at git root) alias:
git config --global alias.remerge '!sh -c "git show HEAD:${2} > ${2}.HEAD; git show ${1}:${2} > ${2}.${1}; git show $(git merge-base HEAD ${1}):${2} > ${2}; $(git config --get merge.tool) ${2}.HEAD ${2} ${2}.${1};"'
Another answer for the same question presents the least confusing solution that is to check out the other branch in a different working copy, which weirdly remembers me of my SVN remote past.
None of the solutions seems adequate to be performed on a routinely basis.
[An example of scenario is when I receive code or text files from someone that is supposed to perform approximate contributions, that need corrections regularly. A more concrete case could be a software spec or even code or a scientific paper being fetched from a software architect or a supervisor after his/her fast-and-dirty review.]
