Here is a reproduction recipe: Goto to some empty directory and do the following commands on (cygwin, git 1.6.0.4): git init echo data1 > f.txt git add f.txt git commit -m second echo data2 >> f.txt git add f.txt git commit -m second echo data3 >> f.txt git add f.txt git commit -m third echo '#!/usr/bin/sh' >myed.sh echo "echo -e '2\ns/pick/s/\np\nw\nq' | ed \$1" >>myed.sh chmod a+x myed.sh export GIT_EDITOR=`pwd`/myed.sh git rebase -p -i master~2 The git rebase will exit with error writing something like the following on stderr: Refusing to squash a merge: 3b9e0d80da20e3543225679906be1cc5cf1a9f44 Constantine On Thu, Jan 15, 2009 at 3:38 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Wed, 14 Jan 2009, Constantine Plotnikov wrote: > >> If I run git rebase --interactive with --preserve-merges option and >> select "squash" for one of the commit, the rebase process fails with the >> message "Refusing to squash a merge: >> 5e775c536654640c173ba71a0af7e84bf8bc618a". However the neither commit >> participating in the squash is a merge commit. Even more, there are no >> merge commits in the repository at all. >> >> From my limited understanding of squash operation, it should fail only >> if one of squashed commits is a merge commit, but it should be possible >> to squash non-merge commits without problem as it looks like quite safe >> and local operation (and I might want to preserve merges that happened >> after squashed commits). Is it the current behaviour a bug or a feature? > > From your description, it seems that you are hitting an ordering bug of > rebase -i -p. > > But without a reproduction recipe (preferably as a patch against our > testsuite), I cannot tell. > > Ciao, > Dscho > > -- 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
