"Stephen R. van den Berg" <srb@cuci.nl> wrote:
quoted text
> 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.

Sorry for wandering into a thread in the middle.  But we've already
been down this road before, and decided the additional header wasn't
worth it from cherry-pick.  What's changed?  The fact that gitk
wants to hyperlink this?  Why can't it just regex out a string of
hex digits longer than 6 and see if there is a commit that matches?

-- 
Shawn.
--
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