Martin von Zweigbergk <martin.von.zweigbe...@gmail.com> writes:
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html