"Stephen R. van den Berg" <srb@xxxxxxx> wrote: > 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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
