Hi Michael, Gelonida wrote: > Hi Michael, > > Michael J Gruber wrote: >> Gelonida venit, vidit, dixit 03.05.2010 11:33: >>> >>> The plan would be: >>> - create a new git repository without the huge file >>> - let everybody clone the new repository and continue working. >>> >>> >>> I thought, that I could squash the commit adding the file, removing the file and >>> the commits in between into one commit. >> You don't need to squash the commits in between. Use git rebase -i A^ if >> A is the commit introducing the large file. Then, either edit that first >> commit (to not add the file) or reorder so that the removal commit is >> squashed into A. > > > I seem to misunderstand your suggestion. > > git rebase -i 740ebdf9b^ > returns following output >> fatal: Needed a single revision >> Invalid base Please ignore me previous reply. It is very embarassing, but I tried it in the wrong window and therefore wrong directory. Now I'm back to other errors. What I did was: git rebase -i 740ebdf9^ # as a very first test I tried to modify nothing at all. # So I just quit the editor window (with about 270 entries) # where I could choose what to pick, squash or ignore The result: the counter counts to about 50 of my 270 commits and then command aborts then > Automatic cherry-pick failed. After resolving the conflicts, > mark the corrected paths with 'git add <paths>', and > run 'git rebase --continue' > Could not apply 67f3f6d... preparation for #241 I guess, that the problem might be. that the version tree looks roughly like this: # first line of tree A-B-C-<forksoff>-D-E-F-G-<all_joined>-H-I-J-<forks_off>--K- #tree continues after K-L-<all_joined>-M-N However, the commit, that I want to fix is commit I, I think git gets lost somehow between J and L Is it normal, that git gets lost wehn rebasing such a structure. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html