Yes. However, most users call find_pack_entry() with a NULL ignore_packed,
so we'd still have to pass in that flag to say whether we should look at
the bit or not.
However, the real issue (?) I think is that the whole "ignore_packed"
logic is crazy. It's the wrong way around. The whole thing is broken.
Rather than marking which ones are "unpacked" and should be ignored, it
should just look at the ones to keep. That's how the filesystem layout
works and that's what "git repack" does anyway.
So I think we should just remove the whole "--unpacked=" thing, and
instead replace it with a "--keep" flag - and then only finding things in
the keep packs if we have a list of them.
That would (a) make the logic a whole lot easier to follow and (b) get rid
of the scalability issue, since you're not really supposed to have more
than one or two .keep files anyway (if that).
Nobody uses "--unpacked=xyzzy" by hand anyway. The only thing that
generates those things is git-repack.sh, so this is not a compatibility
issue, I suspect.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html