Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Clarified point 2.6 in fossil-v-git.wiki to address feedback from Hacker News user balfirevic here: https://news.ycombinator.com/item?id=21974942 |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
f6e04cc4233629b59a5ded9dd488d7e4 |
User & Date: | wyoung 2020-01-08 18:05:39.550 |
Original Comment: | Clarified point 2.6 in fossil-v-git.wiki to address feedback from Hacker News user balfirevic here: https://news.ycombinator.com/item?id=21974942 |
Context
2020-01-08
| ||
18:28 | Added "more" column to the fossil-v-git doc: we have evidence of people reading only the summary table at the top and then reacting to their understanding of that brief one-line characaterization of the difference rather than engaging with the detailed arguments making up the bulk of the article. ... (check-in: fd9e211d user: wyoung tags: trunk) | |
18:05 | Clarified point 2.6 in fossil-v-git.wiki to address feedback from Hacker News user balfirevic here: https://news.ycombinator.com/item?id=21974942 ... (check-in: f6e04cc4 user: wyoung tags: trunk) | |
2020-01-02
| ||
14:35 | Fix the spelling of "legacy" in the "test-fingerprint" command. Also show the current Fossil version in the "test-fingerprint" command. ... (check-in: 2af7fedd user: drh tags: trunk) | |
Changes
Changes to www/fossil-v-git.wiki.
︙ | ︙ | |||
560 561 562 563 564 565 566 | changes on all branches all at once helps keep the whole team up-to-date with what everybody else is doing, resulting in a more tightly focused and cohesive implementation. <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> | > | | < | > > > > > > > > | | | | | | | | | | | > > > | > | 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 | changes on all branches all at once helps keep the whole team up-to-date with what everybody else is doing, resulting in a more tightly focused and cohesive implementation. <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> Because Git commingles the repository data with the initial checkout of that repository, the default mode of operation in Git is to stick to that single work/repo tree, even when that's a shortsighted way of working. Fossil doesn't work that way. A Fossil repository is a SQLite database file which is normally stored outside the working checkout directory. You can [/help?cmd=open | open] a Fossil repository any number of times into any number of working directories. A common usage pattern is to have one working directory per active working branch, so that switching branches is done with a <tt>cd</tt> command rather than by checking out the branches successively in a single working directory. Fossil does allow you to switch branches within a working checkout directory, and this is also often done. It is simply that there is no inherent penalty to either choice in Fossil as there is in Git. The standard advice is to use a switch-in-place workflow in Fossil when the disturbance from switching branches is small, and to use multiple checkouts when you have long-lived working branches that are different enough that switching in place is disruptive. You can use Git in the Fossil style, either by manually symlinking the <tt>.git</tt> directory from one working directory to another or by use of the <tt>[https://git-scm.com/docs/git-worktree|git-worktree]</tt> feature. Nevertheless, Git's default tie between working directory and repository means the standard method for working with a Git repo is to have one working directory only. Most Git tutorials teach this style, so it is how most people learn to use Git. Because relatively few people use Git with multiple working directories per repository, there are [https://duckduckgo.com/?q=git+worktree+problem | several known problems] with that way of working, problems which don't happen in Fossil because of the clear separation between repository and working directory. This distinction matters because switching branches inside a single working directory loses local context on each switch. For instance, in any software project where the runnable program must be built from source files, you invalidate build objects on each switch, artificially increasing the time required to switch versions. Most obviously, this affects software written in statically-compiled programming languages such as C, Java, and Haskell, but it can even affect programs written in dynamic languages like JavaScript. A typical [https://en.wikipedia.org/wiki/Single-page_application | SPA] build process involves several passes: [http://browserify.org/ | Browserify] to convert [https://nodejs.org/ | Node] packages so they'll run in a web browser, [https://sass-lang.com | SASS] to CSS translation, transpilation of [https://www.typescriptlang.org | Typescript] to JavaScript, [https://github.com/mishoo/UglifyJS | uglification], etc. Once all that processing work is done for a given input file in a given working directory, why re-do that work just to switch versions? If most of the files that differ between versions don't change very often, you can save substantial time by switching branches with <tt>cd</tt> rather than swapping versions in-place within a working checkout directory. For another example, you might have an active long-running test grinding away in a working directory, then get a call from a customer requiring that you switch to a stable branch to answer questions in terms of the version that customer is running. You don't want to stop the test in order to switch your lone working directory to the stable branch. Disk space is cheap. Having several working directories, each with its own local state, makes switching versions cheap and fast. Plus, <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil update</tt>. <h3 id="history">2.7 What you should have done vs. What you actually did</h3> Git puts a lot of emphasis on maintaining a "clean" check-in history. Extraneous and experimental branches by individual developers often never make it into the main repository. And |
︙ | ︙ |