On Wed, Feb 13 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > >> (Replying to >> https://public-inbox.org/git/383c14cc.9289.168e61d39e8.coremail.wuzhouhu...@mails.ucas.ac.cn/ >> which curiously I can see there, but not in my inbox (or spam)) >> >> Git's data format doesn't make it easy to find "C" given "B" in a commit >> chain like A->B->C (also there could be any number of "C" >> successors). We need to walk the graph. This shows how to do it: >> >> https://sqlite.org/whynotgit.html#git_makes_it_difficult_to_find_successors_descendents_of_a_check_in I didn't mean to link to that fossil page to start some fossil v.s. git argument. I just remembered having seen the one-liner there. > Of course, the history is not necessarily linear. Even though you > *MUST* know all your parents before having a commit (which means > that when you ask "what came before this commit", there is a > definitive answer that everybody in the world would agree on), you > by definition cannot know all the commits that are children of a > commit (simply because somebody else may be creating a new one), so > the question "what's the next commit" does not make any sense from > that point of view ;-) This is the case with fossil as well. You could create a new descendant commit at any moment. Their point in comparing it to git is that there's nothing intuitive in the UI that exposes this information for the *current* graph, whereas in fossil this is a built-in command: https://fossil-scm.org/xfer/help/descendants Perhaps this information is cheaper to extract these days with the commit graph and we could expose it somehow?
