Re: git pull for update of netdev fails.

["Catalin Marinas" <catalin.marinas@gmail.com>]

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@suse.cz> wrote:
> Dear diary, on Wed, Sep 20, 2006 at 11:14:25PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> 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