Junio C Hamano wrote:
>"Stephen R. van den Berg" <srb@xxxxxxx> 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@xxxxxxxxx> 1220153499 -0700
committer Junio C Hamano <gitster@xxxxxxxxx> 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."
--
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
