On Wed, Nov 07, 2018 at 05:52:05PM +0900, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > The fix here is similar to 4c30d50 "rev-list: disable object/refname > > ambiguity check with --stdin". While the get_object_list() method > > reads the objects from stdin, turn warn_on_object_refname_ambiguity > > flag (which is usually true) to false. Just for code hygiene, save > > away the original at the beginning and restore it once we are done. > > I actually think this is a bit too broad. The calling process of > this program does know that it is feeding list of raw object names > (prefixed with ^ for negative ones), but the codepath this patch > touches does not know who is calling it with what. It would be > safer to introduce a mechanism for the caller to tell this codepath > not to bother checking refnames, as it knows it is feeding the raw > object names and not refnames. > > After all, you can feed things like "refs/heads/master" from the > standard input of "git pack-objects --revs", no? Keep in mind that this is not disallowing "refs/heads/master", nor even disabling the ambiguity checking if we feed a "foo" that exists as both a tag and a branch. It is only disabling the check that when the caller feeds a 40-hex sha1, we do not double-check to make sure that there is not a ref of the same name (which is not even really an ambiguity, but just an informational message for the user; the object id has always and must always take precedence). So yes, the caller does know better "I am only going to feed object ids". But you can likewise look from the callee's perspective: "I am going to take a lot of inputs, and spending time for an informational message for each one is not worth doing". So I think it's justifiable from that point of view. And from a practical point of view, it's much simpler: we do not have teach every caller to specify its input, or risk being slowed down by a low-value informational check. -Peff
