Linus Torvalds [off-list ref] writes:
Also, make the default for refs packing just be an unambiguous "do it",
rather than "do it by default only for non-bare repositories". If you want
that behaviour, you can always just add a
[gc]
packrefs = notbare
in your ~/.gitconfig file, but I don't actually see why bare would be any
different (except for the broken reason that http-fetching used to be
totally broken, and not doing it just meant that it didn't even get
fixed in a timely manner!).
Boy, you are a lot more aggressive than me.
But the fix was in v1.5.0 and we had two feature releases since
then, so it's a good time to do this. Thanks.
On Thu, 24 May 2007, Junio C Hamano wrote:
Boy, you are a lot more aggressive than me.
Heh.
I don't like the http interfaces, so I have a much easier time saying
"they were broken, deal with it" ;)
I also think that we mis-calculated earlier in assuming that prople don't
have lots of branches, and that packing branches was thus much less
important than packing tags.
It's true that in sane git-only environment, you don't have lots of
branches (fifty isn't "lots"). But when importing things from other
environments, I seem to recall people talking about thousands of branches
(since they cannot be merged and they are project-wide rather than some
local entity, they cannot disappear).
So I think it's better to just pack branches aggressively too, and in
fact, once you do that, and http-fetch knows about it, then that also
means that info/refs becomes pointless, because afaik, it doesn't actually
contain anything more than what a modern "packed-refs" file contains.
So in order to take that _next_ step, we need to encourage people to pack
branches, and then at some point we can hopefully just make http-fetch
start ignoring info/refs..
So yeah, I think being aggressive here is a good idea. I really also
wanted to make update-server-info do the pack-refs thing, but to do it
properly we'd need to make the whole pack-refs thing have a nice library
interface, so it was a much bigger (although probably fairly
straightforward) thing.
Linus