On Sun, 18 Jul 2010, Jonathan Nieder wrote: > On the other hand, there are some hard policy questions: > > * Should pre-deletion commits expire more quickly? I think you should have an option to configure expiration of reflogs of deleted branches separately, just like there is currently a way to configure longer expiration time of HEAD reflog, or for stash. With this on low disk size / low quota machine you would be able to turn this feature (this protection) off. > * What happens when you rename one branch to take on the > name of a deleted one? The same as with D/F conflict. If you rename branch 'foo' to 'bar', you also rename its reflog, but logs/refs/heads/bar would not conflict with reflog for deleted branch, logs/refs~/heads~/bar (if you had deleted branch 'bar'). > * What happens when you create a new branch to take the > place of a deleted one? It would either be the same as above, or it would get reflog from deleted branch. The former would be better, if there was in git some command to resurrect deleted branch. > * Should refs outside the refs/heads/ namespace > (like refs/bisect/ and refs/original/) use the same > policy as refs/heads/? I guess that expire policy should be configured per ref, or per namespace. Perhaps gc.<pattern>.reflogExpireDeleted ? But then gc.<pattern>.reflogExpireUnreachableDeleted would be long name, as if compensating for two-letter section name ;-) -- Jakub Narebski Poland -- 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