Re: git rebase --interactive using short SHA-1's internally

Ooops, that's exactly it =) On Sat, Aug 10, 2013 at 2:28 AM, Junio C Hamano gits...@pobox.com wrote: David bouncingc...@gmail.com writes: On 10 August 2013 05:22, Diogo de Campos cam...@esss.com.br wrote: Had some problems rebasing a large repository, fatal error because a short SHA-1 ref

git rebase --interactive using short SHA-1's internally

Had some problems rebasing a large repository, fatal error because a short SHA-1 ref was ambiguous. After a quick inspection of git-rebase--interactive.sh, I found that it uses short refs in a few places (git rev-parse --short). Removing that option fixed my problem. See:

git rebase --interactive forgets strategies after --continue

I had some problems rebasing a repository that had empty commits, which caused the rebase to stop. After continuing it with git rebase --continue, it seems that the strategies I originally gave were forgotten. I quickly glanced at the code, and it seems that a lot of rebase options are stored in

git log --follow filename (with diff.renameLimit=0) not working after subtree add

Problem: git log --follow filename is not working for files after a big move. Scenario: Just performed a git subtree add where big projects were moved into another repository, and I'm not able to view history for a single file. Sample output: Output after subtree add (no output) git log