Jakub Narebski <jnareb@xxxxxxxxx> writes:
> I'd still like the preserving reflogged data during pruning and
> repacking to be optional (default to on).
What does that really _mean_?
Some time after reflog was introduced, you started talking about
it on #git channel saying "you could refer to master@{yesterday}
to get it back, but only unless you pruned".
I think that behaviour was a bug, which was there only because
reflog was bolted onto the plumbing as an afterthought. If the
data reflog keeps is integral part of git (and in v1.5.0 we are
making it so by turning it on by default), you should not have
to say "but only unless" part, which indicates loss of useful
information.
So you either keep objects that reflog entries need, or you
discard reflog entries that point at them when you discard
certain objects you do not need anymore. Removing objects
without removing reflog entries that become stale because of
missing objects takes us back to the "bolted on, not really
integrated" situation. It makes reflog "sometimes work but only
sometimes", and most likely it does not work when the user most
wants it to.
With the current code in 'next', you can discard unwanted reflog
entries using "reflog expire", and then do prune/repack, and can
be assured that the objects that remaining reflog entries want
are still there (modulo bugs -- at least that is the intent).
You could update prune/repack so that they do not look at reflog
data, and have them also remove reflog entries that have become
stale after they do their primary things (either pruning or
repacking), as part of the same invocation. I will not code
that for you because I do not think it is an improvement over
what we have now (for one thing, you cannot prune selectively,
as I already said).
> But failing that I'd
> like to have option to "reflog expire" to remove only specific
> (pattern match, prefix match?) entries, for example to remove
> all the "commit --amend" and StGIT work, but leaving rebases,
> resets, merges and other stuff.
I would say "Patches welcome"; this is not from my sarcastic
side but because I suspect there might be a remote chance that
it might turn out to be useful in some situation. It is just
that my suspicion is not strong enough to tempt me to do so
myself, because I think that even with such an elaborate
selection mechanism in place, what the users would do in
practice would boil down to what --expire-unreachable does.
-
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