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

From: Jeff King <peff@peff.net>
Date: Jan 20, 2016, 02:00 UTC
Message-ID: <20160120020039.GD24541@sigill.intra.peff.net>
In-Reply-To: <xmqqbn8h6mrl.fsf@gitster.mtv.corp.google.com>

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

Show 11 quoted lines

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

Show 6 quoted lines

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