Dear All, I did some rebasing which ended in an unexpected result. This is what I did precisely: - added 3 files to the index, then committed (#1) - realized that a file was left out (not yet tracked), so added + committed it - stashed the local changes - used rebase -i to meld the last commit into the previous one (fixup) - stash pop - added more files to the index, committed (#2) - made some minor changes to a file committed in #1, added, committed - decided to meld into #1 - there were 3 more locally changed files - stashed them - rebase -i, moved the last item one line up, set to fixup, so that it melds into #1 - stash pop: surprise! the stash was empty git log --stat showed that the 3 stashed files got melded into commit #1, too. I didn't expect this. Is this the normal operation? I was able to undo the effects by rebase -i, edit (as in the git rebase manpage under SPLITTING COMMITS), committing again w/o the 3 files I didn't need, saving them to a temp dir, revert them via checkout, rebase --continue, then move the files from temp to have them locally changed again. This is where I would have been if stash pop succeeded. The files in commit #1, #2, and the last 3 locally changed ones where disjunct. I don't know how those 3 locally changed, stashed files ended up in the commit. I checked my command line history, I wasn't adding them. Unfortunately, I wasn't able to reproduce the phenomenon on a test repo, by 3 files: - commit a, b, c - change a, commit - change b, commit - change a, commit - change c - stash c - rebase -i to meld the two a's, making b the last commit - stash pop : it worked Any ideas? I'm using git version 1.7.2.3 under Debian Squeeze AMD64. Please CC me, I'm not on the list. Thanks. Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html