On Tue, Feb 16, 2010 at 1:05 AM, Jon Seymour <jon.seymour@xxxxxxxxx> wrote: > On Mon, Feb 15, 2010 at 10:33 PM, Pavan Kumar Sunkara > > The history is useful for understanding how something came to be - > commits followed backwards down one merge branch will tend to have > some semantic relationship to each other unless your committers are on > acid. Trying to comprehend the evolution of history by replaying it > forwards and keeping track of n parallel threads of development as > they diverge seems like an unnecessarily complicated way of trying to > comprehend the world. > That said, of course, git once had an option to rev-list that I contributed (--merge-order) that attempted to create the best possible linear history by performing a topological sort that minimised the number of "jumps" between semantically unrelated commits in the linear order. The algorithm was kind of cool (based as it was on a conservation of mass analogy), but it eventually got stripped out for various eminently understandable reasons (like no-one was using it, I wasn't maintaining it and it was the only remaining use of a dependency on the open-ssl infinite precision integer arithmetic libraries that complicated the build). git rev-list --topo-order will do a topological sort that guarantees that you never visit a commit before visiting all its ancestors. > jon. > >> -- >> 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 >> > -- 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