Re: [PATCH] filter-branch: resolve $commit^{tree} in no-index case

[Jeff King <peff@peff.net>]

On Tue, Jan 19, 2016 at 05:51:58PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> >> Mph.  We could get the best of both worlds by introducing a "git
> >> rev-parse --compare <a> <b>" that compares object ids.  Actually...
> >> 
> >> How about something like this?
> >
> > Thanks. I had in my head that we could do something like that, but
> > hadn't quite worked it out. I think what you wrote works.
> 
> But wouldn't "diff-tree --quiet" essentially be that command?

I think Jonathan was responding to my point that "diff-tree --quiet"
_isn't_ quite the same, if you have mis-formatted tree objects. If the
sha1s are different, a rev-parse comparison will keep the commit. But
"diff-tree" will actually do the diff, and may consider different sha1s
to have the same content, dropping the second one.

It's a minor point, but I find one of my primary uses for filter-branch
these days is massaging out bogus objects made by older or buggy git
clients (not that I see _that_ many of them; I think it speaks more to
the fact that I don't really use filter-branch much these days).

> > If you want to wrap it up into a patch, I'd be OK with it, but note that
> > it still falls afoul of changing $tree in a user-visible way (so you
> > should note that in the commit message).
> 
> Yes, I think we should take your conservative variant for that exact
> reason.

I'm fine with that, too. We could also do the conservative variant for
"maint", and then do the other with a deprecation warning. I think I
decided I don't care enough to go through those motions myself, but I
don't mind if somebody else wants to.

-Peff