Re: [PATCH 4/4] replace: add a --raw mode for --edit

On Wed, Jun 25, 2014 at 03:33:42PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

One of the purposes of "git replace --edit" is to help a
user repair objects which are malformed or corrupted.
Usually we pretty-print trees with "ls-tree", which is much
easier to work with than the raw binary data.  However, some
forms of corruption break the tree-walker, in which case our
pretty-printing fails, rendering "--edit" useless for the
user.

This patch introduces a "--raw" option, which lets you edit
the binary data in these instances.

Signed-off-by: Jeff King <redacted>
---

Hmmmmm, this feels almost like inviting accidents to make it easy
and limiting the attempt to only one shot at the "transformation"
step.

Will queue, but we can do the same with "cat-file $type >temp", do
some transformation on "temp", doubly make sure what is in "temp" is
sensible and then finally "hash-object -w -t $type temp".  And it
makes me feel uneasy that the new feature seems to make it harder to
do the "doubly make sure" part.

I do not think it is any worse than "--edit" is by itself. True, editing
the binary contents is hard, but we do check that the format is sane
when we read it back in (using the same checks that hash-object does). I
think it would be nice to take that a step further and actually let
hash-object (and "replace --edit") do the more rigorous fsck checks on
created objects.

I do still think even with those automated sanity checks that it makes
sense to double-check the replacement manually. But I think that is one
of the features of replace objects: you are not doing anything
permanent, and can view the object in place. So not only can you examine
the object by "git show $new_sha1", you can see it in place as "git log
-p", etc. And easily back it out with "git replace -d" (or fix it up
again with "git replace --edit") if need be.

-Peff