On 4/23/19, Rowan Worth <row...@dug.com> wrote: > > How can you justify the claim that history was unchanged on trunk between > time (1) and time (2)?
Short answer: I look at the entire DAG, not individual branches. Long answer: From prior discussion and feedback on this thread, I've come to realize that there is a philosophical difference between Fossil and Git. Both systems use a Directed Acyclic Graph of check-ins (the DAG) as their underlying data structure. But in Git, the fundamental unit of management is a branch, which Git defines as a linear sequence of check-ins from a leaf back to the root, whereas in Fossil, the fundamental unit of management is the entire DAG. Git-ers think in terms of branches. And so if you move a node from one branch to another, that changes history. But Fossil-ers think in terms of the entire DAG. Relabeling a node to be on a different branch is just a notational convenience and does not change the DAG in any way, and is hence not a history change. Additional observations that support of this dichotomy: (1) The default synchronization unit in Git is a single branch. You can sync the entire DAG using the --mirror option, but that is rarely done in practice it seems. In Fossil, the default and only synchronization option is the entire DAG. (2) The primary history display in Git/GitHub shows only a single branch (ex: https://github.com/sqlite/sqlite/commits/master) whereas the primary history display in Fossil shows the entire DAG (ex: https://www.sqlite.org/src/timeline). The inability to see the entire DAG on a single screen in GitHub is a persistent source of annoyance to users like me who are accustomed to Fossil. (3) Git puts special emphasis on rebase, which is used to transfer or replicate a span of check-ins from one branch into another. Having all the important check-ins on a single branch is important if your focus is on that one branch. Fossil, in contrast, keeps the entire DAG in view all at once, and so is no issue with keeping span of check-ins remain on a separate arm of the DAG and merely merge in the changes. The Git approach makes sense in a highly distributed project like the Linux Kernel, where there are many thousands of developers each working on their own branches and where it is desirable to prune the DAG down to a more manageable size by omitting extraneous arms. The Fossil approach works better for cathedral-style development where there is a small team of contributors, all of which know each other and work together daily, and where developers want to keep track of everything that is going on, for improved situational awareness and project coherence. SQLite Git Mirror Update: I made enhancements last night so that any future branch relabelings that occur in SQLite should automatically be mirrored into the Git repository on GitHub. (Aside: See the interesting 5-way join used to determine which "git update-ref" commands are needed on each incremental export here: https://www.fossil-scm.org/fossil/artifact/b0ace47d4c6a?ln=1492-1505) There are definite management advantages to relabeling branches, and so I will not preclude such actions in SQLite moving forward, though I will try to keep relabelings to a minimum. Nevertheless, users of the Git mirror should keep in mind that I think in terms of the entire DAG, not individual branches, and so if you are tracking SQLite development in a Git clone, you should to take steps to ensure that you do not find yourself stalled on a side-tracked branch. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
