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. -Peff -- 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
