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

On Wed, Nov 26, 2008 at 5:40 PM, Johannes Schindelin
[off-list ref] wrote:

Hi,

On Wed, 26 Nov 2008, Ondrej Certik wrote:

quoted

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