On Thu, 25 Jan 2007, Junio C Hamano wrote: > > On the other hand, I do not think it is worth unpacking non-tags > that are packed when --all is not given, so... Exactly. I'd much rather have git pack-refs --all --prune just pack everything once and for all. Afterwards, if you do just git pack-refs it will keep everything that was packed packed, and any loose refs (which might be loose because they are new, but perhaps because they simply got overridden by being changed) will not be added to the pack unless they are tags. Which should be the semantics with my patch applied. The above actually makes tons of sense: operations like big imports (or clones) might want to start out with *everything* packed, but then as we update, commit and modify, what we actually want to do is to basically let the branches that are actively developed "become unpacked" as they are updated. So the "repack refs that were already packed, or refs that are tags" is actually a very sane default. It's not just that we don't want to lose the refs entirely, it's also that what we actually want to do by default is to pack the stuff we have reason to believe won't be actively changing. Tags automatically fall under that heading (which is why it makes sense to pack them by default in the first place!) but so does any ref that was already packed, and hadn't become unpacked since the last repack. By definition, such a ref isn't "actively changing" even if it isn't a tag. No? Linus - 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