Re: [RFC] cherry-pick using multiple parents to implement -x

["Stephen R. van den Berg" <srb@cuci.nl>]

Junio C Hamano wrote:
>"Stephen R. van den Berg" <srb@cuci.nl> writes:
>I think the commit object name -x records in the commit message of the
>cherry-picked one is noticed by gitweb to give you an easy access.  You
>could teach gitk a similar trick, and that would not just help cherry
>picking but also reverts, and a fix-up commit that says "This fixes the
>regression introduced by commit 90ff09a5".

Checking the on-disk format I see that it has been defined in a rather
extensible way.

If we were to put the SHA1-ref somewhere in the commit message, 
finding references to a certain commit through cherry-picks becomes
rather disk/CPU-intensive.

Would there be any objections against extending the on-disk format to
accomodate something like the following:

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

Whereas cherry-pick would (optionally) generate a cousin reference for every
commit it picks.

I'm willing to do the work to fix up git-core to support the new field.
-- 
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."