Paolo Bonzini wrote:
>> commit 7df437e56b5a2c5ec7140dd097b517563db4972c
>> tree a006f20b481d811ccb4846534ef6394be5bc78a8
>> parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123
>> parent bbb896d8e10f736bfda8f587c0009c358c9a8599
>> cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9
>> cousin a1184d85e8752658f02746982822f43f32316803
>> author Junio C Hamano <gitster@xxxxxxxxx> 1220153499 -0700
>> committer Junio C Hamano <gitster@xxxxxxxxx> 1220153499 -0700
>What about "origin", and making it propagated through cherry-picks? In
"origin" gives a better sense of direction, so maybe that's better, yes.
>other words, if I "cherry-pick -x" A generating B, and do the same on B
>generating C, C should have A as origin. Also, "git cherry-pick -n -x"
>should add the commit to a list of origins somewhere so that "git
>commit" can reuse it.
That is debatable, and should be configurable with a switch.
It depends on the way of operation, I guess.
If one picks A -> B, and then B -> C, then usually for C you want B
to be the origin to indicate that the patch has been tested and shaved
to fit from A -> B, and further polished to fit from B -> C.
Usually backporting involves shaving the patch slightly to fit the older
branch, and in that case it is truly more honest to point back to B
instead of A from C. And besides, you can follow the chain to C -> B -> A
if you like, no information is lost.
>Furthermore, "git cherry" should use origins if available.
That is one of the places in git that needs to accomodate the new field,
luckily the impact on the rest of git-core is rather minimal, I think.
--
Sincerely,
Stephen R. van den Berg.
The Horkheimer Effect: "The odds of it being cloudy are directly proportional
to the importance of an astronomical event."
--
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
