Re: Seriously broken "git pack-refs"

On Thu, 25 Jan 2007, Junio C Hamano wrote:

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