git rebase -i -p broken?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Consider this scenario:
- commit some patch (named 'a')
- merge a random branch
- commit a fix to patch a
- since I haven't pushed yet, I want to squash a and a-fix together, to prevent bisect problems
- fire up 'git rebase -i -p a^'

Now the problems begin:
- the todo list shows up the branch's commits as well as my current branch. But I don't want to commit the branch's commits in my own branch. Replaying the merge should be enough. Looks like a missing --first-parent somewhere. - removing the spurious commit from the todo, and moving a-fix after a and marking it as a squash action, I get
  Refusing to squash a merge: 51ca22d7afb7433332ae41d0c2e3bab598048c21
 even though that's not a merge
- using git commit --amend instead of squash confuses git in some other way

Attached is a script that generates a test case. With some $EDITOR hacks it can even be convinced to be an automated test case.

All this using 1.6.0.2.

--
error compiling committee.c: too many arguments to function

!#/bin/sh -e

git --version
mkdir repo
cd repo
git init
touch a
touch 0
git add 0
git commit -m 'zeroth commit'
git add a
git commit -m 'first commit'
git checkout -b branch
touch b
git add b
git commit -m 'second commit (branch)'
git checkout master
touch c
git add c
git commit -m 'third commit'
git merge branch
touch d
git add d
git commit -m 'fifth commit'
git rebase -i -p HEAD~4

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux