Re: git fast-export | git fast-import doesn't work

From: Ondrej Certik <ondrej@certik.cz>
Date: Nov 26, 2008, 17:21 UTC
Message-ID: <85b5c3130811260921s474bc724hb74b54e21e8be912@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0811261739110.30769@pacific.mpi-cbg.de>

On Wed, Nov 26, 2008 at 5:40 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 13 quoted lines

> Hi,
>
> On Wed, 26 Nov 2008, Ondrej Certik wrote:
>
>> I am also trying to make the example simpler. I tried to squash the
>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
>> fails after squashing about 600 commits. Still investigating.
>
> 1500... wow.
>
> The best idea would probably be to just "edit" the first, delete the rest
> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
> the command line (when git rebase stops after the "edit" command).

That worked, thanks! My original repo:

A -- B -- ... --- D --- E --- ...

where E and the rest of the commits (there are branches and merges in there) are the ones that I need to preserve, but all the commits between B and D can be squashed (~1500 of them). So I created a branch:

A -- B -- ... --- D

then squashed the commits using the technique you described above, so now I have:

A -- BD --

and now I would like to append "E -- ..." to it -- is there any way to do that? I tried rebase, but that destroys all the branches and merges and those are necessary to reproduce the fast-export bug.

>
> rebase -i was _never_ meant for such _massive_ interactions; that's just
> too much for a shell script.

In fact, I think it would work, but there is probably another bug, that I am hitting, maybe due to whitespace problems --- in the original repository, the patches are linear, but when I create a branch before the failing patch and then cherry-pick it (that should work), it fails and creates conflicts. The same behavior is with git rebase. So I'll investigate more and report it in a separate thread, as it is not related to fast-export.

Ondrej