Stephen Boyd [off-list ref] writes:
You might want to look at using the parse options API. It has options
for verbose and abbrev builtin, so you don't have to do any extra
work....
Why do people even think a change like this to a _plumbing_ command is
desirable?
Admittedly, there already is "verbose" option that adds redundant
information to the output of this particular plumbing, which might
arguably be equally wrong as what this patch does, but I think it is
excusable. At least it lets the Porcelain script that uses the command
avoid calling 'git cat-file commit' to find out the title of the commit.
But --abbrev does not even add any information. If implemented correctly
(which earlier iteration did not even do), it may not lose information by
choping the output too short to make it ambiguous, but as others pointed
out about using grep in the calling Porcelain to filter (or more likely,
sift the lines into "+" and "-" bins) to shoot down -d/-D options, I do
not see the point of adding --abbrev to this plumbing command very much.
Junio C Hamano, 31.05.2009:
Why do people even think a change like this to a _plumbing_ command is
desirable?
git-cherry is plumbing? In git(1) it is listed as porcelain.
And the plumbings show-ref, ls-files and ls-tree support --abbrev.
Markus
Junio C Hamano wrote:
Stephen Boyd [off-list ref] writes:
quoted
You might want to look at using the parse options API. It has options
for verbose and abbrev builtin, so you don't have to do any extra
work....
Why do people even think a change like this to a _plumbing_ command is
desirable?
Admittedly, there already is "verbose" option that adds redundant
information to the output of this particular plumbing, which might
arguably be equally wrong as what this patch does, but I think it is
excusable. At least it lets the Porcelain script that uses the command
avoid calling 'git cat-file commit' to find out the title of the commit.
But --abbrev does not even add any information. If implemented correctly
(which earlier iteration did not even do), it may not lose information by
choping the output too short to make it ambiguous, but as others pointed
out about using grep in the calling Porcelain to filter (or more likely,
sift the lines into "+" and "-" bins) to shoot down -d/-D options, I do
not see the point of adding --abbrev to this plumbing command very much.
I was tempted to say the same thing, but I decided to leave it up to the
maintainer ;-) Maybe if there was a compelling use case it would make
more sense?
Or, would it make more sense to just use git-log? Right now you can do
git log --oneline --cherry-pick <head>..<upstream> and get close. Maybe
we can add a "--cherry" option to git-log which will act like git-cherry
by finding unmerged commits?