how to squash a few commits in the past

Hi,

I posted already a similiar question about how to squash the all the commit hostory older than a certain commit into one commit.

This question is slightly different.

I'm having a git repository.

Suddenly I noticed, that git pull became rather slow.

The reason: One of the team members accidentally commited a very huge file together with some useful sources. a few commits later he noticed his error and removed the huge file.

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.

How could I do this?

Thanks a lot for your help.

Gelonida venit, vidit, dixit 03.05.2010 11:33:

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.

If everything looks fine people can pull and rebase. Note that in the source repository, there will still be a large "blob" until you prune and repack.

Michael

Hi Michael,

Michael J Gruber wrote:

I seem to misunderstand your suggestion.

git rebase -i 740ebdf9b^ returns following output

what am I missing?

Hi,

Gelonida wrote:

In case it is relevent:

My git version: git version 1.6.3.3

Hi Michael,

Gelonida wrote:

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

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.

Hi,

On Mon, May 3, 2010 at 11:20 PM, Gelonida <gelonida@gmail.com> wrote:

While performing an interactive rebase, conflicts can often occur and this is quite normal.

The problem and solution is described in that message. Open the file, resolve the conflict and continue the rebase operation.

-- Ram

Hi Ragu,

Ramkumar Ramachandra wrote:

Yes merging manually could be a theortical solution, but I really don't understand, why I should merge anything at all.

The history is purely linear at the places where I want to squash.

These two commits precede a few more consecutive commits, traverse then a tree which forks to multiple branches, which partially cherrypick from each other and will then join again to a unique linear sequence.

If I have a history of several hundred commits and I am asked several times to merge, just because I want to squash two consecutve commits without any branches going out or in, then something (probably the way I try to attack the problem or much less likely a mysterious git bug) is kind of wrong.

I'm still looking for a solution, where I specify only the commits to be squashed and everything else stays untouched without any further userinteraction

Am 5/3/2010 11:33, schrieb Gelonida:

Use 'git filter-branch':

  git filter-branch \
    --index-filter 'git rm --ignore-unmatch --cached the/huge/file' \
    --prune-empty \
    -- --all

The --prune-empty removes the commit that removed the file from the history if the removal of the/huge/file was the only thing it did.

If you have tags that must be rewritten, add "--tag-name-filter cat" to the command before "--".

Try this in a backup copy or clone first!

-- Hannes