Dear diary, on Wed, Sep 20, 2006 at 11:14:25PM CEST, I got a letter where Johannes Schindelin <Johannes.Schindelin@xxxxxx> said that... > Another, even more serious problems with rebasing: You can introduce a bug > by rebasing. Meaning: git-rebase can succeed, even compilation is fine, > but the sum of your patches, and the patches you are rebasing on, is > buggy. And there is _no_ way to bisect this, since the "good" version can > be gone for good. Yes, I agree that this really is a problem, but that's a fundamental limitation. At least for StGIT-maintained floating branches the latest bleeding edge StGIT could fix that. (Except that the problem outlined by Linus is present here as well, first prune will wipe your older patch versions and your patch log will be useless - Catalin? Can we store the older patch versions references in something like .git/refs/patches-old/?) And except that it does that only for you - there should be a way to conveniently mirror (clone+pull) the patch stack setup. > As for the problem git-rebase tries to solve: you can get a clean branch > by cherry-picking what you have into a temporary branch, for the sole > purpose of being history clean. That's not really a reliable option because after getting your patches through Christopher Hellwig you _will_ need to go back and poke some patches in that history. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) - 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