On Thu, Jan 28, 2021 at 08:17:40PM -0500, Taylor Blau wrote: > On Thu, Jan 28, 2021 at 07:30:56PM -0500, Jeff King wrote: > > On Mon, Jan 25, 2021 at 06:37:34PM -0500, Taylor Blau wrote: > > > > > +pack.writeReverseIndex:: > > > + When true, git will write a corresponding .rev file (see: > > > + link:../technical/pack-format.html[Documentation/technical/pack-format.txt]) > > > + for each new packfile that it writes in all places except for > > > + linkgit:git-fast-import[1] and in the bulk checkin mechanism. > > > + Defaults to false. > > > > We may want to teach fast-import about this, too, but I think it's OK to > > draw the line here for now (it's already reasonably well known that the > > generated packs aren't amazing and benefit from repacking). > > Maybe this was worth explaining in the documentation, but this choice > was intentional. I'm not aware of any use-case that keeps the packs > generated by fast-import around for very long (i.e., I'd expect any 'git > fast-import' to be pretty quickly followed by a 'git repack -ad'), so I > don't think we'd want to spend time generating a reverse index for a > pack structure that we're about to immediately discard. One case where I imagine they are kept is in remote-helpers that use the import/export mechanism (e.g., something interacting with remote-hg). I suspect people there just live with the somewhat lousy packs, and then perhaps occasionally "git repack -adf". That would give them .rev files then, too. But as I said, I think it's OK to ignore this for now. If somebody with an interest in fast-import wants to add support later, they can. -Peff
