On Sun, Dec 17, 2006 at 12:29:25AM +0100, Jakub Narebski wrote: > > I am thinking about teaching fsck-objects and prune to keep > > revisions recorded in the reflog; we would need an end-user > > way to prune older reflog entries and I would appreciate > > somebody codes it up, but even without it, people can always > > use "vi" or "ed" on reflog files ;-). > > I'd rather not have prune keep revisions recorded in reflog. Reflog > keeps also amended commits, and blobs from incrementally staged > commits. Or perhaps make it an configuration option, default to > true for new users (or have an option to git-prune to ignore reflog). I think that is quite near to other issues: we already have other pieces of information that we would like to sometimes have ignored and sometimes not, when running fsck-objects/prune. Namely, revisions hidden by grafts, as already discussed on this list. An idea I had to handle that case, and which could be useful with the current problem, as well as others, like dealing with stgit's patch logging, would be to define "reachable commits" using a modular architecture. That way we would be able to select what we want fsck-object/prune to consider reachable, in objects reachable from: - raw "parents" field of commit objects - the latter as modified by info/grafts - reflogs - stgit patchlogs The set of rules to consider could be declared in repo-config, thus stgit would be able to declare that its patchlogs should not be ignored, and people wishing to prune commits hidden by grafts in one repo could just remove the "raw-parents" rule from their repo's config. Obviously, mentionning stgit-specific rules here immediately suggests a plugin-based architecture. Does that make any sense ? -- Yann. - 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