Re: [WIP PATCH] Manual rename correction
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 2, 2012, 22:51 UTC
- Message-ID
- <7v6290di1m.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120802223733.GA28217@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 27 quoted lines
> On Wed, Aug 01, 2012 at 03:10:55PM -0700, Junio C Hamano wrote: > ... >> When you move porn/0001.jpg in the preimage to naughty/00001.jpg in >> the postimage, they both can hit "*.jpg contentid=jpeg" line in the >> top-level .gitattribute file, and the contentid driver for jpeg type >> may strip exif and hash the remainder bits in the image to come up >> with a token you can use in a similar way as object ID is used in >> the exact rename detection phase. >> >> Just thinking aloud. > > Ah, I see. That still feels like way too specific a use case to me. A > much more general use case to me would be a contentid driver which > splits the file into multiple chunks (which can be concatenated to > arrive at the original content), and marks chunks as "OK to delta" or > "not able to delta". In other words, a content-specific version of the > bup-style splitting that people have proposed. > > Assuming we split a jpeg into its EXIF bits (+delta) and its image bits > (-delta), then you could do a fast rename or pack-objects comparison > between two such files (in fact, with chunked object storage, > pack-objects can avoid looking at the image parts at all). > > However, it may be the case that such "smart" splitting is not > necessary, as stupid and generic bup-style splitting may be enough. I > really need to start playing with the patches you wrote last year that > started in that direction.
I wasn't interested in "packing split object representation", actually. The idea was still within the context of "rename".