git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: [Question] Signature calculation ignoring parts of binary files

From
Randall S. Becker <rsbecker@nexbridge.com>
Date
Sep 13, 2018, 17:55 UTC
Message-ID
<005e01d44b8a$ef1221e0$cd3665a0$@nexbridge.com>
In-Reply-To
<xmqqva79ffpv.fsf@gitster-ct.c.googlers.com>
On September 13, 2018 1:52 PM, Junio C Hamano wrote:
Show 11 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> >
> >> The scenario is slightly different.
> >> 1. Person A gives me a new binary file-1 with fingerprint A1. This
> >> goes into git unchanged.
> >> 2. Person B gives me binary file-2 with fingerprint B2. This does not
> >> go into git yet.
> >> 3. We attempt a git diff between the committed file-1 and uncommitted
> >> file-2 using a textconv implementation that strips what we don't need
to
Show 17 quoted lines
> compare.
> >> 4. If file-1 and file-2 have no difference when textconv is used,
> >> file-2 is not added and not committed. It is discarded with impunity,
> >> never to be seen again, although we might whine a lot at the user for
> >> attempting to put
> >> file-2 in - but that's not git's issue.
> >
> > You are forgetting that Git is a distributed version control system,
> > aren't you?  Person A and B can introduce their "moral equivalent but
> > bytewise different" copies to their repository under the same object
> > name, and you can pull from them--what happens?
> >
> > It is fundamental that one object name given to Git identifies one
> > specific byte sequence contained in an object uniquely.  Once you
> > broke that, you no longer have Git.
> 
> Having said all that, if you want to keep the original with frills but
somehow
> give these bytewise different things that reduce to the same essence (e.g.
> when passed thru a filter like textconv), I suspect a better approach
might be
> to store both the "original" and the result of passing the "original"
through
> the filter in the object database.  In the above example, you'll get two
> "original"
> objects from person A and person B, plus one "canonical" object that are
> bytewise different from either of these two originals, but what they
reduce
> to when you use the filter on them.  Then you record the fact that to
derive
> the "essence" object, you can reduce either person A's or person B's
> "original" through the filter, perhaps by using "git notes" attached to
the
> "essence" object, recording the object names of these originals (the
reason
> why using notes in this direction is because you can mechanically
determine
> which "essence"
> object any given "original" object reduces to---it is just the matter of
passing
> it through the filter.  But there can be more than one "original" that
reduces
> to the same "essence").
I like that idea. It turns the reduced object into a contract. Thanks.
Previous: Junio C Hamano
Message 10 of 10 in “[Question] Signature calculation ignoring parts of binary files”
  1. Randall S. BeckerSep 12, 2018
  2. Johannes SixtSep 12, 2018
  3. Randall S. BeckerSep 12, 2018
  4. Randall S. BeckerSep 12, 2018
  5. Junio C HamanoSep 12, 2018
  6. Randall S. BeckerSep 13, 2018
  7. Junio C HamanoSep 13, 2018
  8. Randall S. BeckerSep 13, 2018
  9. Junio C HamanoSep 13, 2018
  10. Randall S. BeckerSep 13, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.