andreas.koenig.7os6VVqR@xxxxxxxxxxxxxxxx (Andreas J. Koenig) writes: >>>>>> On Thu, 19 Jan 2012 09:23:01 +0100, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> said: > > js> Am 1/19/2012 4:29, schrieb Andreas J. Koenig: > >> - A -> B -> C - D -> > >> \ / > >> - E - F - > >> > >> A v5.15.5 > >> B v5.15.5-20-gfd76d40 > >> C v5.15.5-81-gcfe287a > >> D v5.15.5-159-ga71d67b > >> E v5.15.4-110-g27b29ec > >> F v5.15.4-169-g3582575 > > js> I haven't looked at the actual history, but given the names of the commits > js> as produced by git-describe, I doubt that your history graph sketched > js> above is correct. Doesn't it look more like this: > > js> A -- B -- C -- D -- > js> / / > js> -- X -- E -- F > > js> where X is v5.15.4? > > Yes, thank you for finding that out. X is actually v5.15.4-109-g3ea0c58 > and since there was a long timespan between the start of the development > of the code and the merge (May-Nov), the gitk presentation got a bit > complex to read. (This is somewhat off-topic, so Andreas is on Cc: and the list is on To:) I doubt --simplify-by-decoration alone would make it easier to view such a complex and long history, but I wonder if we can use the same logic to help users in a case like this. Instead of only keeping tagged versions in the result to show topology, perhaps we can allow the user to feed a list of "key points in history" as command line arguments and apply the same kind of simplification to help visualizing the topology? -- 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