On Fri, Jul 08, 2016 at 10:14:33AM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > That sounds reasonable. And if they *do* end up taking any time to > > traverse, it's because they weren't reachable from other anchoring > > points, so taking the extra time to traverse them seems fine. > > The only thing that is hard is to clearly define _what_ are the new > anchoring points. > > It cannot be "anything directly under .git that has all-caps name > that ends with _HEAD". The ones we write we know are going to be > removed at some point in time (e.g. "git reset", "git bisect reset", > "git merge --abort", etc.). We do not have any control on random > ones that the users and third-party tools leave behind, holding onto > irrelevant objects forever.
"We don't understand it, so it must not be important" does not seem like a safe approach. An object matching "[_A-Z]*HEAD" might act more like a detached HEAD, referencing objects the user wants to hold onto permanently. And even FETCH_HEAD might point to objects the user expected to stick around until they chose to ignore them; what makes FETCH_HEAD a less legitimate head to work with than refs/heads/scratch? (Or, for that matter, what about an ugly merge in MERGE_HEAD that the user put off until after a vacation?) The only downside of "holding onto irrelevant objects forever" is storage space, which the user can easily reclaim by removing HEADs they don't want. The downside of pruning objects the user wanted is data loss. Why not just mark all those objects as roots for reachability permanently, and let the user remove them if they want to prune those objects? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
