From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Sunday, November 05, 2017 6:28 AM
"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 'relative to' was meaning the user's expectation about this particular
command. For a non-expert user, who may not have come across cat-file yet,
their world view may not extend beyond 'Git describe <this>' for me.
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.
I realised, after sending, that this was probably the method for
non-ambiguous shortened oid's. Thanks for the reminder.
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.
Correct, it was the option selection aspect.
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.
Correct. We ask to describe an object, but then the option choices may vary
by type.
The new [blob] synopys only lists <options>, while the old [commit-ish]
shows specifics. It wasn't clear if the options are the same for both. I
quess they are the same once the cat-file -t has done its bit. Its only the
speed that's affected.
As a side note, the commit message example don't show any pathspec that is
not in the top level directory.
--
Philip
