Re: [PATCH 2/4] revisions passed to cherry-pick should be in "default" order

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2012, 21:05 UTC
Message-ID: <7vehnacxkf.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAOeW2eEbe9_m_QSbsJUbWPhf6G17X3vqbh__TCefrB0G2VKXdw@mail.gmail.com>

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

Show 5 quoted lines

> To connect to the other mail I sent on this thread (in parallel with
> yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the
> commits in the same order as "git cherry-pick HEAD~2..HEAD" (which
> would give the same result if passed to 'rev-list --no-walk' for a
> linear history) or in the order specified on the command line?

Definitely the latter; I do not think of any semi-reasonable excuse to do otherwise.

> I couldn't find any conclusive evidence of what was intended in
> either log messages or test cases.

Do not take the "multi-commit handling" that was bolted on to cherry-pick and revert long after these commands with a single commit form were polished and have become stable too seriously and its behaviour cast in stone. There is no reason to believe the bolted-on part was designed with sufficient thoughts behind it, nor was implemented with the same competency as the code before it was introduced. I recall myself applying these patches after only cursory review, saying "Meh, I wouldn't do multiple commits anyway, and bugs found by people can be fixed later" ;-).

It is OK to consider its doneness as "the developers declared success based on their limited testing; it internally still sorts, but sorting a range by timestamp happens to yield the correct result most of the time, and this bug was not found until much later. There certainly are other bugs, at both implementation and design level, yet to be discovered." phase of its lifecycle.