On Tue, Jan 10, 2012 at 6:38 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> The parameter to "git shortlog" that appears later should also be updated
> to match this, by the way, even though that should not affect the outcome
> in any way.
No, don't do that part.
Why?
Remember: there can be *multiple* merge bases. The expression
git shortlog ^$baserev $headrev
always works, but changing "baserev" to "merge_base" will suddenly
break for the multiple merge-bases case.
> I am however not sure what would happen when there are more than one merge
> bases. I guess those who throw pull requests are not supposed to be doing
> merges in reverse direction, so it should not matter ;-)
The other cases don't really care. For them, "show one merge-base" is
fine, and they are "end-point" operations (like "diff") that really
cannot handle a set of commits anyway.
But for "git shortlog", switching to using the merge base would
actually start showing commits that shouldn't be shown. It's
fundamentally a set operator, and does the right thing in the presense
of multiple merge-bases (which "diff" and "since commit XYZ" are
clearly not set operators, although arguably you could try to show all
merge bases for the "since" case).
Linus
--
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