The last question of mine was/is a rethorical one.
Consider the typical use case I describe above. The developer usually
has just created a commit in the developmentbranch, tested it, and deems
the patch worthwhile enough to backport it to the latest stable branch.
So he cherry picks the from the development branch to the latest stable
branch.
Then tests it, and decides to backport it to the older stable branch,
so he cherry-picks it again, and commits it there too. The is repeated
in rapid succession on three older stable branches as well.
Basically that means that for the patch itself, there is a path in
history to follow as well. I.e. the patch itself evolves over time.
Now, when another developer makes an additional change to this patch
in one of the stable versions, it is very helpful to actually be able to
have git tell you where the original patch came from and to follow back
the chain upward. It allows you to forward/backward port the new change
more easily.
Basically, the normal parent links allow you to follow evolving
snapshots of the complete source-tree, whereas the origin links allow
you to follow evolving snapshots of a patch.
As it happens, the shortest way to describe a patch in git is by
specifying two commits of which the difference is exactly your patch.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html