On Thu, Jul 07, 2016 at 09:34:02PM -0700, Junio C Hamano wrote: > Josh Triplett <josh@xxxxxxxxxxxxxxxx> writes: > > This could result in data loss, if a user expected that having an object > > referenced from those places would protect it from pruning. > > Yeah, luckily, nobody expects such. I do not think any of our > document says nothing other than HEAD like CHERRY_PICK_HEAD is > reachability anchoring point; they are designed to be transient. I can imagine at least one scenario that would result in data loss here: git pull a URL (not referenced via any ref other than FETCH_HEAD/MERGE_HEAD), get a merge conflict, get halfway through resolving it, set that repository aside for a while, do something that triggers a gc, then attempt to finish and commit. Unlikely, but not impossible. Same reason the reachability logic looks at the index. (I originally encountered this because I intended to add another HEAD-like ref in .git, so I started investigating the logic around such HEADs.) > Because they are designed to be transient, I do not think there is > any downside (other than the initial start-up cost) to including > them in reachability computation. Because they are meant to be > transient, the objects anchored by them would be reachable from > other anchoring points anyway. 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. - Josh Triplett -- 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