Re: how to squash a few commits in the past

[Gelonida <gelonida@gmail.com>]

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.