rebase

I'm trying to rebase a commit. However, any time I run git rebase -i f83eff3ffc8 , for example, a MacVim window opens, that's empty (there is no information in the file). Then once I write and close the file (even though it's empty), I get a Successfully rebased and updated refs/heads/clicktocall-hotfix message. The file name is .git/rebase-merge/git-rebase-todo . I also tried running it with sudo but this didn't make a difference. What could be the problem? I've never successfully completed a rebase. Kevin Burke I was using Macvim and needed to run mvim with the -f option, as documented here:

I'm wondering if there's an upper limit to the number of commits that a git repository can handle. In a solo project I'm working on right now, I've been coding locally, committing/pushing changes in git, then pulling the changes on my development server. I treat this as an easier alternative to working locally and uploading changes via FTP... Fortunately/Unfortunately it's such an easy workflow that I sometimes go through many edit/commit/push/pull/browser-refresh cycles while coding. I'm wondering if this is going to turn around and bite me somewhere down the line. If it's likely to be a

Can I squash a range of commits for a local feature/topic branch using rebase that does not include the most recent commit? This is for commits that I want to prepare before they get merged and pushed to a public repo. I was working quickly and made a bunch of minor changes with poor titles and descriptions that I want to squash into two or three separate logical commits with a great comments. Can I select a range of commits between 329aed9 and af39283 that could be at any point in this feature branch's short history? git rebase -i RANGE_START_COMMIT_ID RANGE_LAST_COMMIT_ID Thanks! You could

If there are multiple developers working on a feature branch, and we need to periodically bring in changes from master, there are two approaches that I know of: developers communicate that they have the latest changes from the published feature branch. Then one developer rebases onto master and force pushes. Other developers pull down the new feature branch and everyone continues developing. any developer merges master in whenever they like, no one ever force pushes. my questions: am i right that these are the possible workflows? with the second workflow, when it's time to bring the feature

I've decided to retrospectively commit a history, that was never in Git, from an other old version control system. So I've created an orphan branch "newroot", and imported commits from the other version control system to it. Following question Insert a commit before the root commit in Git? The "newroot" branch ended up with files exactly matching the root commit of the "master" branch. Now I want to rebase the "master" branch onto the "newroot" orphan branch, like: git rebase --onto newroot --root master The problem is that I get prompted to resolve all merge conflicts. There are hundreds of