Linus Torvalds <torvalds@xxxxxxxx> 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. - 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