Documentation Source Text

Check-in [71cccf3d65]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More "whynotgit.html" updates.
Timelines: family | ancestors | descendants | both | branch-3.28
Files: files | file ages | folders
SHA3-256: 71cccf3d658085493243a119441963bcb175312ff07219af5af9705eb33d63e6
User & Date: drh 2019-04-30 20:37:35
Context
2019-05-02
16:25
Attempt to clarify the scope of when UPSERT processing applies. check-in: aae75b6ac2 user: drh tags: branch-3.28
2019-04-30
20:37
More "whynotgit.html" updates. check-in: 71cccf3d65 user: drh tags: branch-3.28
20:15
Further enhancements to the whynotgit.html page. check-in: 763fc99770 user: drh tags: branch-3.28
Changes
Hide Diffs Side-by-Side Diffs Ignore Whitespace Patch

Changes to pages/whynotgit.in.

     9      9   [https://git-scm.org|Git] version control system.
    10     10   SQLite uses
    11     11   [https://fossil-scm.org/|Fossil] instead, which is a
    12     12   version control system that was specifically designed
    13     13   and written to support SQLite.
    14     14   
    15     15   <p>
    16         -People often wonder sometimes ask why SQLite does not use the
           16  +People often wonder why SQLite does not use the
    17     17   [https://git-scm.org|Git] version control system like everybody
    18     18   else.
    19     19   This article attempts to answer that question.  Also,
    20     20   in <a href="#getthecode">section 3</a>, 
    21     21   this article provides hints to Git users
    22     22   about how they can easily access the SQLite source code.
    23     23   
................................................................................
    31     31   <p>
    32     32   This article is <u>not</u> advocating that you switch your projects
    33     33   away from Git.  You can use whatever version control system you want.
    34     34   If you are perfectly happy with Git, then by all means keep using
    35     35   Git.  But, if you are wondering if there isn't something better,
    36     36   then maybe try to understand the perspectives presented below.
    37     37   Use the insights thus obtained to find or write a different and
    38         -better version control system, or to make
    39         -improvements to Git.
           38  +better version control system, or to just make
           39  +improvements to Git itself.
    40     40   
    41     41   <h2>Edits</h2>
    42     42   
    43     43   <p>
    44     44   This article has been revised multiple times in an attempt
    45     45   to improve clarity, address concerns and misgivings,
    46     46   and to fix errors identified on
    47     47   [https://news.ycombinator.com/item?id=16806114|Hacker News],
    48     48   [https://www.reddit.com/r/programming/comments/8c2niw/why_sqlite_does_not_use_git/|Reddit]
    49     49   and
    50     50   [https://lobste.rs/s/slcntl/why_sqlite_does_not_use_git|Lobsters].
    51     51   The complete edit history can be seen at
    52     52   [https://sqlite.org/docsrc/finfo/pages/whynotgit.in].
    53         -(Usage hint: Click on any two nodes of the graph in the file history
    54         -page linked above to see a diff between the two versions.)
    55         -
           53  +(Usage hint: Click on any two nodes of the graph for a diff.)
    56     54   
    57     55   <h1>A Few Reasons Why SQLite Does Not Use Git</h1>
    58     56   
    59         -<p>
    60         -One could summarize the reason why SQLite does not use Git in
    61         -a single sentence:  The lead SQLite developer finds Git to be
    62         -unpalatable.  If you like Git and want to use it, that's great.
    63         -I would rather use something better.
    64         -
    65         -<p>
    66         -The following are a few of the reasons why I do not like Git:
    67         -
    68     57   <h2>Git does not provide good situational awareness</h2>
    69     58   
    70     59   <p>
    71     60   When I want to see what has been happening on SQLite (or any of
    72     61   about a dozen other projects that I work on) I visit the
    73     62   [https://sqlite.org/src/timeline|timeline] and in a single
    74     63   screen I can see a quick summary of all the latest changes,
................................................................................
   195    184   Git keeps the complete DAG of the check-in sequence.  But branch
   196    185   tags are local information that is not synced and not retained
   197    186   once a branch closes.
   198    187   This makes review of historical
   199    188   branches tedious.
   200    189   
   201    190   <p>
   202         -As an example, consider display of a single historical
   203         -branch of SQLite as rendered by GitHub and by Fossil:
          191  +As an example, suppose someone (perhaps a customer) asks you:
          192  +"What ever became of that 'prefer-coroutine-sort-subquery' branch
          193  +from two years ago?"
          194  +You might try to answer the query by consulting the history in
          195  +your version control system, thusly:
   204    196   
   205    197   <ul>
   206    198   <li><b>GitHub:</b> [https://github.com/sqlite/sqlite/commits/prefer-coroutine-sort-subquery]
   207    199   <li><b>Fossil:</b> [https://sqlite.org/src/timeline?r=prefer-coroutine-sort-subquery]
   208    200   </ul>
   209    201   
   210    202   <p>
................................................................................
   278    270   <p>
   279    271   As of 2019-03-20, there is now an 
   280    272   [https://github.com/sqlite/sqlite|official Git mirror] of the
   281    273   SQLite sources on GitHub.
   282    274   
   283    275   <p>The mirror is an incremental export of the 
   284    276   [https://sqlite.org/src/timeline|canonical Fossil repository] for
   285         -SQLite.  A cron-job updates the GitHub repository at 17 minutes after
   286         -the hour, ever hour.
          277  +SQLite.  A cron-job updates the GitHub repository once an hour.
   287    278   This is a one-way, read-only code mirror.  No pull requests or 
   288    279   changes are accepted via GitHub.  The GitHub repository merely copies
   289    280   the content from the Fossil repository.  All changes are input via
   290    281   Fossil.
   291    282   
   292    283   <p>
   293    284   The hashes that identify check-ins and files on the Git mirror are