Re: git pull for update of netdev fails.

[Shawn Pearce <spearce@spearce.org>]

Linus Torvalds <torvalds@osdl.org> wrote:
> 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.