Subject: Re: squash commits deep down in history

From: Henning Moll <[email-masked]>
Date: Fri, 24 Oct 2014 00:20:10 +0200

Am 23.10.2014 um 22:08 schrieb Johannes Sixt:
> Use git-replace do construct a squashed commit that replaces the last 
> child in each run such that its parent points to the parent of the 
> first in the run. Then use a git-filterbranch without filters to burn 
> the parenthood into the history. -- Hannes 
Wow, cool. Thanks a lot for the hint.

I managed to do the following: Suppose i have the following history

A - B - C - D   <-master

and i want to squash B and C together. First i create a temporary branch 
on A and switch to it. Then i cherry-pick B and C without commit. So all 
the changes are merged into the index. Then i commit a single commit 
"M". The history now looks like

   M             <-temp
  /
A - B - C - D   <-master

Using

$ git replace C M

leads to

    temp
         |
         v

A -     M - D   <-master

As far as i understand, such a repalce is something like a "symbolic 
link". Is that right?

This is interesting: Before filter-branch, the deletion of the replace 
would lead to the initial situation (ABCD). After filter-branch, the 
history is (AM'D'). The replace still exists but is now something like a 
"dead link". I may come to life again after "git resetting" to somewhere 
before filter-branch. Even "before" creating the replace (the replace 
ref itself is not part of the history). Even if you gor before creation 
of M: The link still works as long as M is not garbage collected. I was 
very irritated after resetting to where i commited D, and still seeing 
A-M-D.

Somehow logical, somehow crazy! I am still a git learner ;-)

Two questions remain for me:

1. Is there a more elegant way to build M?
2. Having a replace "in place" before filter-branch: Is there a way to 
find out what the replace is hiding? A simple "git log C" produces 
"M-A". How to get "C-B-A"?

Best regards
Henning