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

> Jeff King <p...@peff.net> writes:
> > 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 <p...@peff.net>
> > ---
> 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.

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

Reply via email to