Oops, I screwed it up

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