2

I'm trying to squash a few commits into a pull-request-ready package for a github project I'm hoping to contribute to, but using git rebase -i master isn't giving me the options I expect (based on reading on StackOverflow and elsewhere. This is the first time I've attempted to squash commits, so I'm probably just missing something.

The history of the project is something along the lines of:

# On branch master
git pull origin master
git fetch upstream
git rebase upstream/master
git checkout -b feature
git commit -m "some work"
git commit -m "a little more work"
git commit -m "finishing up feature"
git checkout master
git pull origin master
git fetch upstream
git rebase upstream/master
git checkout feature

at this point there have been no changes in origin/master or upstream/master, so even without rebasing my feature branch is linear with both origin and upstream. When I do git rebase -i master, none of my commits are listed in the editor that pops up, which is completely blank, and the output of the rebase is Successfully rebased and updated refs/heads/feature.

I know I could use 

git checkout master
git merge --squash feature

but my understanding is that I'll lose all the history if I do that.

Is there another way to accomplish what I want, or am I just missing the obvious?

UPDATE

What I expect to see is an editor with the commits I've made in my feature branch listed so that I can select which ones to pick and which to squash. What I actually see is an empty editor, which makes me wonder if because my current branch is linear to my master branch, nothing needs to be rebased and so no commits show up in the editor (although I suppose I would have expected to get a "nothing to rebase" sort of message instead of the success message noted above)

cori
  • 8,666
  • 7
  • 45
  • 81
  • `git rebase -i master` should do what you expect if you have `feature` checked out. Try `git rebase -i master feature` if you're not on `feature` already. – Koraktor Dec 10 '12 at 15:24
  • i am most definitely on `feature`, and trying your suggestion results in the same behavior, but thanks! – cori Dec 10 '12 at 15:38
  • so what options do you expect, and what do you actually see? – Useless Dec 10 '12 at 16:13
  • @Useless, question updated – cori Dec 10 '12 at 16:24
  • OK, so how does `gitk --all` (or `git log --graph`, or the gui of your choice ...) show the relationship between origin/master, upstream/master, master and feature? – Useless Dec 10 '12 at 16:30
  • completely linear. upstream/master is a direct ancestor of origin/master, which is a direct ancestor of master, which is a direct ancestor of feature, which contains the commits I want to squash. – cori Dec 10 '12 at 16:36
  • @Useless: The branch layout doesn't matter with `git rebase -i`, it will always ask for what to do, even in a linear history. – Koraktor Dec 10 '12 at 16:42
  • @Koraktor that's enough for me. apparently the issue is with my editor, when using either GitExtensions or git at the windows command line, git was opening Notepad, which I had replaced with ConText, which is somewhat buggy. Once I switched to using GitExtensions's built-in editor i got the expected editor content. Thanks! – cori Dec 10 '12 at 16:55
  • Check it out [Squash Commits with Git](https://davidwalsh.name/squash-commits-git) Update: This may help you -> [Stackoverflow: git-interactive-rebase-no-commits-to-pick](http://stackoverflow.com/questions/6485508/git-interactive-rebase-no-commits-to-pick) – Niraj Kaushal Feb 03 '16 at 23:49

1 Answers1

0

As noted in the comments, the issue wasn't with the git rebase -i master command at all, but instead with my editor, which wasn't handling the input from git to appropriately display the available commits.

Changing to a different editor resolved the issue.

cori
  • 8,666
  • 7
  • 45
  • 81