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?
Constantine
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
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
[off-list ref] wrote:
Hi,
On Wed, 14 Jan 2009, Constantine Plotnikov wrote:
quoted
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