Git merge --no-commit tracked files without committing them

Question

On branch AI had two 'stories', one which I wanted committed to master, one I did not.

As these changes were not on feature branches, I needed to separate the two somehow. I used

git merge --no-commit --no-ff A 

while on master. This gave me a staging area to tweak as expected, and I

git reset file 

on those files relating to the unwanted commit. Is this approach incorrect? The result was unexpected. The files were not added (as desired) but the record of them was. Git tracked them as removed files! Now when merging back into A from master it tries to delete the uncommitted work. Its very strange as master never had some of these files. This is extremely inconvenient, can anyone suggest how I might go about 'synchronising' these changes? Or perhaps a better approach going forward, why would --no-commit do this?

Answer 1

I think most clean way is to create two branches story1 and story2 from the mergebase of A and master. Then separate A commits by cherry-picking and editing/spitting commits. So you have two new branches for each story separately. Then you could easily merge.