Question

What i want to do is to merge changes between 2 commits into current sandbox as local changes. Is that possible and easy to do?

I know you can use diff but its not as easy as reviewing local changes. Local changes allow you to easily revert/modify/add changes as you go through review. The closest i got to what i want was this:

1 checkout the commit before my branch was created

2 chreate a new temporary branch (just for safety)

3 create patch between beginning and end of the branch like

git diff f9802a30b589503cd61e..4f6ee3fb127d958b5621 --patience --ignore-space-at-eol  > diff.txt

4 apply patch to local sandbox (still in temporary branch)

git apply diff.txt

There are issues with this approach though. (A) Its very slow and painful. (B) im getting tons of whitespace warning. (C) probably this is not the way to do it 😉

Is there a better way to do it?

Answer 1

(I’m assuming before you start that git status is clean, so as not to risk losing any local changes.)

Since you’re created a temporary branch anyway, why don’t you just use git merge othercommit to merge in the other commit? Your working tree and index will be updated with the results of the merge, of course – it’ll create a new commit, but if you don’t like that you can just checkout your original branch to get back. If you want to make additional changes to fix up the results of the merge, that should really be in additional commit on top of the merge anyway.

Alternatively, you don’t even need to create a temporary branch – you can always use git reset --hard (with care!) to move your branch back to where it was.

Incidentally, on (B) you can pass --whitespace=nowarn to git apply to stop those warnings, or change what’s considered a whitespace error by changing the config option core.whitespace.

---

The above is what I would recommend, but to answer the exact form of question you’re asking, you could try the following:

You can do a merge without committing the result by using:

git merge --no-commit othercommit

… which will update your working copy and index (staging area) with the results of the merge but won’t create a commit. However, this is slightly risky – if you then go on to stage further changes that weren’t in either of the parents, and then commit that, you’ll have created an evil merge, which can cause various problems when you’re examining the history later.

Similarly, if you just want to see what the effect of a merge would be, you could do:

 git merge --squash othercommit

… which will change your working tree to the results of the merge, and stage all those changes, but won’t create a commit. However, unlike with --no-commit, if you do then go on to commit, that won’t record othercommit as a parent of the new commit.