Re: git pull for update of netdev fails.

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 20, 2006, 16:28 UTC
Message-ID: <20060920162810.GB23260@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0609200915550.4388@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> wrote:

Show 12 quoted lines

> On Wed, 20 Sep 2006, Petr Baudis wrote:
> > 
> >   I personally don't think "throwing away" history is an issue. You can
> > print the old sha1 and it is still in the database so you can recover
> > it.
> 
> No it isn't. Once you've lost the reference, you can't really depend on it 
> any more in the long run.
> 
> A lot of people do things like "git repack -a -d" by hand, and we've tried 
> to encourage people to do so in cron-jobs etc. We've even had patches 
> floating around that do it automatically after a pull.

Ouch.  That's really bad.

I knew it but didn't realize it until just now.

	git repack -a -d
	git branch -D foo
	git repack -a -d

and *poof* no foo. Even if you somehow have its SHA1 and haven't used `git prune` you still have just pruned the thing away and can't look it up anymore.

git branch -D is just the obvious way of doing it. git rebase is slightly less obvious for some people (perhaps more so for others). git fetch with a '+' in a Pull: line is even less obvious, especially if you have reflog enabled for exactly that reason.

So we've managed to encourage people to run prune without actually running prune. Should we just integrate prune and repack -a -d with the 'rm -rf /' command? Perhaps a kernel module at the VFS layer would do the trick? I hear we have some kernel folks nearby. :-)

-- 
Shawn.