Petr, (I'm slow at replying and even slower at implementing anything over the next 2-3 weeks - paternity leave :-)) On 23/09/06, Petr Baudis <pasky@xxxxxxx> wrote:
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.
I wasn't following this thread (well, any thread in the last days) but the current patch history implementation in StGIT is prune-safe as it generates additional commits to keep the history. If you undo an operation (push, refresh), the undo will be recorded in the patch history (that's really immutable). However, deleting a patch would delete the corresponding history log as well. -- Catalin - 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