Am 30.08.2014 um 15:16 schrieb Jeff King:
On Fri, Aug 29, 2014 at 07:59:32PM -0700, Shawn Pearce wrote:
I agree it is probably a bug on the sending side, but I think last time
this came up we decided to try to be liberal in what we accept. c.f.
http://thread.gmane.org/gmane.comp.version-control.git/232305/focus=232310
IIRC they aren't valid pack files to contain duplicates.
Once upon a time JGit had a bug and android.googlesource.com returned
duplicate objects in a Linux kernel repository. This caused at least
some versions of git-core to fail very badly in binary search at
object lookup time or something. We had a lot of users angry with us.
:)
I know Nico said its OK last year, but its really not. I don't think
implementations are capable of handling it.
We do detect and complain if --strict is given. Should we make it the
default instead? I think it is still worthwhile to have a mode that can
handle these packs. It may be the only reasonable way to recover the
data from such a broken pack (and that broken pack may be the only copy
of the data you have, if you are stuck getting it out of a broken
implementation on a remote server).
Sounds reasonable; being able to extract code from broken repos --
especially in this real-world case -- is beneficial.
My only nit with patch 2: Petr Stodulka <pstod...@redhat.com> and Martin
von Gagern <martin.vgag...@gmx.net> should be mentioned as bug reporters.
René
--
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
