"Philip Oakley" <philipoakley@xxxxxxx> writes: > Is this not also an alternative case, relative to the user, for the > scenario where the user has an oid/sha1 value but does not know what > it is, and would like to find its source and type relative to the > `describe` command. I am not sure what you wanted to say with "source and type RELATIVE TO the describe command". The first thing the combination of the user and the describe command would do when the user has a 40-hex string would be to do the equivalent of "cat-file -t" to learn if it even exists and what its type is. With Stefan's patch, that is what describe command does in order to choose quite a different codeflow from the traditional mode when it learns that it was given a blob. > IIUC the existing `describe` command only accepts <commit-ish> values, > and here we are extending that to be even more inclusive, but at the > same time the options become more restricted. Do you mean that the command should check if it was given an option that would not be applicable to the "find a commit that has the blob" mode, once it learns that it was given a blob and needs to go in that codepath? I think that would make sense. > Or have I misunderstood how the fast commit search and the slower > potentially-a-blob searching are disambiguated? I do not think so. We used to barf when we got anything but commit-ish, but Stefan's new code kicks in if the object turns out to be a blob---I think that is what you mean by the disambiguation.
