Re: What's cooking in git.git (topics)

[Yann Dirson <ydirson@altern.org>]

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 ?

--