Marko Macek <marko.macek@xxxxxxx> writes: > Shawn Pearce wrote: >... >> I have: >> >> git repo-config --global core.logAllRefUpdates true >> >> especially since Junio fixed it to only create logs for heads and >> not tags. That way its on by default for me. But I think it should >> be on by default in the next version of Git. > > Why is it not useful for tags for having logs? When I make a tag that says "this is the v1.2.0 release", it is expected it won't change in the future, ever. I _can_ make mistake and tag a wrong commit under v1.2.0 name, in which case I may have to replace it with another corrected tag, but recoding that mistake does not really add value. So most of the time ref-log for a tag would contain only one entry per file, its creation, but that creation time is already recorded in the tag object itself anyway. At times, it may be useful to have some floating tag that point at the "latest", or "today's", but that use is a minority. For these minority cases, you can manually create an empty file under .git/logs/ directory to record their updates. The configuration mechanism only kicks in when there is no such existing file to prime the process, and not creating ref-log for tags by default is the sensible thing to do. > I also have a question: > > Does git-fsck-objects/prune check the ref logs? They deliberately ignore ref-log for the same reason lost-found does not drop found refs under .git/refs hierarchy. This only matters if you somehow rewind an existing branch in order to lose part of its history, using "reset --hard HEAD~n" or "rebase". If the updates to your branch tips always build on top of the previous (either by commiting on top of the current, merging on top of the current, or fast-forwarding), and if you never rewind the branch, the commits recorded in the ref-log for the branch are always ancestors of the tip of the branch, so checking ref-log does not give you anything other than slowing the operation down. However, if you rewind the tip of a branch, the story changes. Until the next "prune", objects reachable from the ref-log of the branch but not reachable from the tip of the branch are still available in your object store and in a pinch you can recover them, but after a "prune" they will be lost forever if they do not have any other references. So it might seem that they should be protected from pruning. But if you did so, you can never remove cruft from your object store once you make a mistake. You can clean up your history by a reset and/or a rebase, and cleaning up to _lose_ part of the history was the reason you rewound the branch in the first place. In other words, running 'prune' is a conscious act of saying "I know I am not in the middle of something; I thought over what I've done recently, salvaged necessary bits from what I discarded earlier, and there is nothing that need to be salvaged later anymore -- I have refs to what I need. Now go clean up the cruft from my object store". - 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