On Tue, Jan 19, 2016 at 05:51:58PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html