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

From: Junio C Hamano <junkio@cox.net>
Date: Dec 17, 2006, 00:19 UTC
Message-ID: <7v4prv8jcn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <em1vgj$bc3$1@sea.gmane.org>

Jakub Narebski <jnareb@gmail.com> writes:

Show 23 quoted lines

> Junio C Hamano wrote:
>
>> Things that I feel should be done need to be done to complete
>> v1.5.0 are:
> [...]
>>  - now reflog is enabled by default for user repositories, I
>>    have two worries about its effect, fortunately can be killed
>>    with a single stone.
>> 
>>    * the reflog grows unbounded;
>> 
>>    * revisions recorded in the reflog can be pruned out,
>>      rendering some entries in reflog useless.
>> 
>>    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.

That is exactly why I would want to protect them from pruning; the current alternative, git-lost-found, is usable but not so nice from the point of view of end users . The user should be able to use show-branch --reflog, or use a different mode of operation in the log family [*1*] to inspect the otherwise lost commits, and as you prune unneeded reflog entries you could prune those objects.

You could certainly arrange things the other way around. As a part of prune, you can prune the reflog entries that refer to commits that were pruned away and no longer available.

HOWEVER, that is very unfriendly to the end users, because they do not have much control in what 'prune' removes. If you want to keep a dozen or so recent states just in case you may have to salvage rewound states (e.g. you may realize your amended commit was faulty), how would you tell 'prune' to keep only those objects from getting pruned?

That's right -- by holding references to them. And that is exactly how making prune to take reflog into account would help the user. If the user has unwanted commits (say, everything that are more than 7 days old, plus this and that commits you rewound an hour ago), they can be pruned away from reflog and prune will take care of the rest.

So doing it in the way I described makes a lot more sense than doing the other way around.

[Footnote]

*1* I have to warn you that this would require quite different code to walk the commits, but certainly a lot simpler than the ancestry traversal. If you are interested in learning the internals, this may be a good project to start with.