Re: [RFC] cherry-pick using multiple parents to implement -x
- From
Stephen R. van den Berg <srb@cuci.nl>
- Date
- Sep 8, 2008, 13:42 UTC
- Message-ID
- <20080908134222.GA20998@cuci.nl>
- In-Reply-To
- <48C522F6.7090308@gnu.org>
Paolo Bonzini wrote:
Show 8 quoted lines
>> commit 7df437e56b5a2c5ec7140dd097b517563db4972c >> tree a006f20b481d811ccb4846534ef6394be5bc78a8 >> parent ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123 >> parent bbb896d8e10f736bfda8f587c0009c358c9a8599 >> cousin 6ffaecc7d8b2c3c188a2efa5977a6e6605d878d9 >> cousin a1184d85e8752658f02746982822f43f32316803 >> author Junio C Hamano <gitster@pobox.com> 1220153499 -0700 >> committer Junio C Hamano <gitster@pobox.com> 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."