On Wed, Nov 26, 2008 at 5:40 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
