Git rebase -i HEAD ~ 7 - only "noop" is shown in the editor

Question

I am trying to crush a commit that is in HEAD into one that is a bit backward. However, when I run git rebase -i HEAD~7 , only noop forwards me to the editor! I am completely confused about how this should work.

I work in the ( cleanup ) branch that I created (using checkout -b cleanup ... in SHA1, which I found in reflog ) after I had my first rebase experience and accidentally deleted all these commits; I'm not sure what a parent branch is (if that matters, here).

I am just trying to do what I read many times: I want to modify some code a bit, which is not the last. Regardless of whether the crush application or just corrects it when I get to this point, I don't know.

I also see this in STDOUT when the editor starts after running the rebase command shown above:

 $ git rebase -i HEAD~7 usage: git rev-list [OPTION] <commit-id>... [ -- paths... ] limiting output: --max-count=<n> ... 

In addition to the HEAD~7 link, I tried to specify all SHA1 and various refspecs for local and remote branches. The same result for everything ...

What am I missing? Thank you for your help!

---

Edit:

 $ git log --oneline HEAD~7..HEAD d0fd20e temp Fix resume_cities table ea2ffdf Fix db/seeds.rb to reflect recent database structure modifications dbd2b8b Add several models/scaffolds that go along with the Geonames tables 9759091 Fix name of the ResumeSkill model file. 3fc3134 Added the SHA1 for the previous commit to the comments on the migration, to help link back to that. bacbeb2 Consolidate database migrations! READ ME! 0c49a57 Moved back to gem versions of linkedin, omniauth, and twitter 

This is the bacbeb2 command that I want to change with d0fd20e

---

Following @MarkLongair’s recommendation, I added set -x to /usr/lib/git-core/git-rebase--interactive and saw the following weird output:

 $ git rebase -i HEAD~7 [... output muted for brevity, see the full output, here: http://gist.github.com/1163118] + read -r shortsha1 rest + sed -ns/^>//p + git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit --abbrev=7 --reverse --left-right --topo-order 2c51946812a198ca908ebcad2308e4b8274624b3...d0e9ff6d9c1f8bc374856ca2a84ad52d6013b5bf usage: git rev-list [OPTION] <commit-id>... [ -- paths... ] limiting output: --max-count=<n> --max-age=<epoch> --min-age=<epoch> --sparse --no-merges --remove-empty --all --branches --tags --remotes --stdin --quiet ordering output: --topo-order --date-order --reverse formatting output: --parents --children --objects | --objects-edge --unpacked --header | --pretty --abbrev=<n> | --no-abbrev --abbrev-commit --left-right special purpose: --bisect --bisect-vars --bisect-all + test t = + test -s /home/ryan/Projects/social-jobs/.git/rebase-merge/git-rebase-todo + echo noop [...] 

I say "strange output" because if I run the rev-list command directly from my shell, it works as expected:

 $ git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit --abbrev=7 --reverse --left-right --topo-order 2c51946812a198ca908ebcad2308e4b8274624b3...d0e9ff6d9c1f8bc374856ca2a84ad52d6013b5bf >0c49a57 Moved back to gem versions of linkedin, omniauth, and twitter >bacbeb2 Consolidate database migrations! READ ME! >3fc3134 Added the SHA1 for the previous commit to the comments on the migration, to help link back to that. >9759091 Fix name of the ResumeSkill model file. >dbd2b8b Add several models/scaffolds that go along with the Geonames tables >ea2ffdf Fix db/seeds.rb to reflect recent database structure modifications >d0e9ff6 !temp Fix resume_cities table !temp 

Answer 1

This problem was caused by installing my.bashrc IFS:

 # remove the space character from IFS # (http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html#IFS) IFS="`printf '\n\t'`" 

I generally can’t remember why I put it there. I am sure that this has something to do with "correcting UNIX / Linux file names," as indicated by my inclusion of this URL. I do not know.

Despite this, I deleted this expression and: POOF! More problems!

Many thanks @MarkLongair for the help!

Answer 2

Update. At the end of my answer there is an explanation of this behavior, but I left debugging suggestions here if they are useful to everyone.

---

I'm not sure that I have a real answer here, but I will explain what happens with my best understanding. When calling git rebase -i HEAD~7 git should only output noop to .git/rebase-merge/git-rebase-todo if this file is empty or does not exist. We know that this is not a permissions problem, since this file (containing "noop" and commented lines) is successfully created as a result. The fact that you see an error from git rev-list on the terminal also indicates that the problem is really related to how git rev-list called. In git v1.7.4.1, with the command line you specify, the list of commits to include should be found from the following:

 git rev-list --no-merges --cherry-pick --pretty=oneline --abbrev-commit \ --abbrev=7 --reverse --left-right --topo-order HEAD~7...HEAD 

Note that this is slightly different from what is offered on the man page ( git log <upstream>..HEAD ), since the range uses ... instead of ..

I would suggest, as you see the error from git rev-list , that this is a problem. Could you try this and see what is the way out? If this works, then I suspect that an earlier error occurred due to which this command line was incorrect. Since interactive reboot is implemented as a shell script, you can pretty easily learn it by editing the script using sudo editor /usr/lib/git-core/git-rebase--interactive and adding set -x at the top, something like:

 #!/bin/sh set -x # # Copyright (c) 2006 Johannes E. Schindelin # SHORT DESCRIPTION [...] 

Then, if you try to run git rebase -i HEAD~7 , you should see every command the script executes, and maybe see what is wrong with calling git rev-list .

I hope for some help.

---

Update: it turns out that the problem was that the survey had IFS , which included only the tab and the new line, and not the default space, tab and new line.

This causes a line issue in git-rebase--interactive starting with

 git rev-list $MERGES_OPTION --pretty=oneline [...] 

... since MERGES_OPTION set to --no-merges --cherry-pick . With the default IFS (which includes a space), this will be split into two parameters after replacing the variable. However, with IFS , which does not include a space, --no-merges --cherry-pick will be interpreted as the only and clearly unknown argument, resulting in a message about using git rev-list and empty output being passed to the script.

Nice puzzle :)