Karthik Nayak <karthik.188@xxxxxxxxx> writes: > To just get rid of reflogs from a repository, I think 'git reflog drop' > or something similar would indeed be a better way to go about it. As you > stated, with this patch, we could still face the issue wherein the > administartor could re-enable reflog and we're back to square one. Exactly. > Why I think this patch is important, is because while there could be > existing reflogs in a repository, if one doesn't care about _reflogs_ > there could be significant performance gains while migrating repos from > one backend to the other, while also leaving the reflogs behind. Sure. It could be done with a combination of "git reflog drop && git refs migrate" (or "git refs migrate && git reflog drop", if the migrated-to backend performs better when it drops reflogs). With "git refs migrate --skip-reflog" alone, we are very limited. We can lose reflogs _only_ when we are migrating. Doing it _during_ migration may very well be more efficient than dropping first and then migrate (or the other way around), so I do not have much against the "migrate --skip-reflog" existing. But I find it backwards to add it first _before_ we have a tool that is more generally applicable to wider situations, i.e., "reflog drop". IOW, it feels as if we are worried about icing on the cake long before we actually bake the cake.
