[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Seriously broken "git pack-refs"
From:       Linus Torvalds <torvalds () linux-foundation ! org>
Date:       2007-01-26 6:24:35
Message-ID: Pine.LNX.4.64.0701252218540.25027 () woody ! linux-foundation ! org
[Download RAW message or body]



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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]